From mpls-bounces@ietf.org Sun Aug 1 01:24: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 BAA08559; Sun, 1 Aug 2004 01:24:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Br8sm-0002Ha-Vr; Sun, 01 Aug 2004 01:27:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Br8ka-0007IP-PI; Sun, 01 Aug 2004 01:19:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Br8jW-0006uw-Ej; Sun, 01 Aug 2004 01:18:09 -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 BAA08277; Sun, 1 Aug 2004 01:18:05 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Br8m6-0002C1-RX; Sun, 01 Aug 2004 01:20:47 -0400 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i7158DLl005706; Sat, 31 Jul 2004 22:08:15 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (sj-dial-4-94.cisco.com [10.19.235.222]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id WAA06857; Sat, 31 Jul 2004 22:08:07 -0700 (PDT) Message-Id: <4.3.2.7.2.20040801005948.06eb6b58@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 01 Aug 2004 01:07:35 -0400 To: , , "TEWG" , From: Jean Philippe Vasseur Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: Bill Fenner Subject: [mpls] PCE BOF - Thursday August 5, 13:00 to 15: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: , Content-Type: multipart/mixed; boundary="===============0480077262==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a --===============0480077262== Content-Type: multipart/alternative; boundary="=====================_231100534==_.ALT" --=====================_231100534==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, Just to let you know that the set of slides for the PCE BOF will be available next Monday morning (http://www.olddog.co.uk/60/pce.ppt) Cheers, JP and Adrian. Path Computation Element BOF (PCE BOF) 60th IETF, San Diego, August 2004 Routing Area Ads: Alex Zinin (zinin@psg.com), Bill Fenner (fenner@research.att.com) BOF Chairs: JP Vasseur (jvasseur@cisco.com), Adrian Farrel (adrian@olddog.co.uk) Description: In certain MPLS TE networks it may be beneficial or desirable to have path computation performed by a distinct node (termed the Path Computation Element PCE) that is not the LSR that needs to know the path. This BOF examines the scope of such function, what extensions to existing protocols might required, what additional protocols may need to be developed, and whether there is cuase and support for this work within the IETF. Proposed WG Charter Organizational Overview The PCE working group coordinates the work within the IETF of defining the operation of path computation elements within the Internet. Path computation elements are responsible for computing paths through IP networks for uses such as traffic engineering so that a prime consumer of such paths might be an MPLS-TE LSR. Areas of responsibility will include the collection of attributes relevant to the computation of paths, the discovery by LSRs of available path computation elements, the communication with LSRs for the request of path computation, the collaboration between path computation elements within the network, and analysis of path computation algorithms with a view to ensuring consistency between computed paths. The working group will work closely with many working groups in the Routing Area including the OSPF, IS-IS, IDR, MPLS and CCAMP working groups. Working Group Scope The PCE working group scope includes: - Definition of Generalized Traffic Engineered LSP paths computation techniques involving Path Computation Element(s). This includes the intra IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path computation for Point-to-Point, Point-to-Multipoint and Multipoint-to-Multipoint TE LSPs. - Definition of protocol-independent metrics and constraints defining path quality measurement criteria, algorithm complexity and scalability criteria related to path computation techniques. - Definition of requirements for communication between LSRs and PCEs including routing extensions in support of PCE discovery techniques within an IGP area and across multiple IGP areas, ASes and Provider networks, and including the development of new protocols or protocol extensions for requesting path computation and supplying responses. Any protocol extensions will developed in conjunction with the working groups in charge of the specific protocols. - Specification of routing (OSPF, ISIS, BGP) and signalling extensions (RSVP-TE) required by PCE-based path computation techniques. The extensions will developed in conjunction with the working groups in charge of the specific protocols. - Specification of requirements and protocol extensions related to the policy, security and confidentiality aspects of PCE-based path computation techniques involving PCEs of multiple Providers. - Definition of MIBs, management procedures related to the protocol extensions defined by the WG In doing this work, the WG will closely work with at least the following other WGs: CCAMP, MPLS, ISIS, OSPF, IDR. The WG will also cooperate with the ITU-T and OIF. Goals and Milestones Dates for milestones to be decided later. - Post strawman WG goals and charter. - Submit WG document defining the framework and applicability of the PCE model. - Select a single candidate protocol from communication between LSRs and PCEs. - Submit document(s) that define various path computation models - Submit an analysis document examining the requirements for coherent computation techniques and the implication of cooperation between PCEs. - Submit a document defining the protocol for communication between LSRs and PCEs. - Submit document(s) defining extensions to routing and signalling protocols necessary to support the use of a PCE model within MPLS networks. - Submit a document defining MIB modules for modeling and management of PCE systems. --=====================_231100534==_.ALT Content-Type: text/html; charset="us-ascii" Hi,

Just to let you know that the set of slides for the PCE BOF will be available next Monday morning (http://www.olddog.co.uk/60/pce.ppt)

Cheers,

JP and Adrian.

Path Computation Element BOF (PCE BOF)
60th IETF, San Diego, August 2004

Routing Area Ads: Alex Zinin (zinin@psg.com),
Bill Fenner (fenner@research.att.com)

BOF Chairs: JP Vasseur (jvasseur@cisco.com), Adrian Farrel (adrian@olddog.co.uk)

Description:
In certain MPLS TE networks it may be beneficial or desirable to have path
computation performed by a distinct node (termed the Path Computation
Element PCE) that is not the LSR that needs to know the path. This BOF
examines the scope of such function, what extensions to existing protocols
might required, what additional protocols may need to be developed, and
whether there is cuase and support for this work within the IETF.

Proposed WG Charter

Organizational Overview
The PCE working group coordinates the work within the IETF of defining the
operation of path computation elements within the Internet. Path
computation elements are responsible for computing paths through IP
networks for uses such as traffic engineering so that a prime consumer of
such paths might be an MPLS-TE LSR. Areas of responsibility will include
the collection of attributes relevant to the computation of paths, the
discovery by LSRs of available path computation elements, the communication
with LSRs for the request of path computation, the collaboration between
path computation elements within the network, and analysis of path
computation algorithms with a view to ensuring consistency between computed
paths. The working group will work closely with many working groups in the
Routing Area including the OSPF, IS-IS, IDR, MPLS and CCAMP working groups.

Working Group Scope

The PCE working group scope includes:
- Definition of Generalized Traffic Engineered LSP paths computation
techniques involving Path Computation Element(s). This includes the intra
IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path
computation for Point-to-Point, Point-to-Multipoint and
Multipoint-to-Multipoint TE LSPs.
- Definition of protocol-independent metrics and constraints defining path
quality measurement criteria, algorithm complexity and scalability criteria
related to path computation techniques.
- Definition of requirements for communication between LSRs and PCEs
including routing extensions in support of PCE discovery techniques within
an IGP area and across multiple IGP areas, ASes and Provider networks, and
including the development of new protocols or protocol extensions for
requesting path computation and supplying responses. Any protocol
extensions will developed in conjunction with the working groups in charge
of the specific protocols.
- Specification of routing (OSPF, ISIS, BGP) and signalling extensions
(RSVP-TE) required by PCE-based path computation techniques. The extensions
will developed in conjunction with the working groups in charge of the
specific protocols.
- Specification of requirements and protocol extensions related to the
policy, security and confidentiality aspects of PCE-based path computation
techniques involving PCEs of multiple Providers.
- Definition of MIBs, management procedures related to the protocol
extensions defined by the WG
In doing this work, the WG will closely work with at least the following
other WGs: CCAMP, MPLS, ISIS, OSPF, IDR. The WG will also cooperate with
the ITU-T and OIF.

Goals and Milestones
Dates for milestones to be decided later.
- Post strawman WG goals and charter.
- Submit WG document defining the framework and applicability of the
PCE model.
- Select a single candidate protocol from communication between LSRs
and PCEs.
- Submit document(s) that define various path computation models
- Submit an analysis document examining the requirements for coherent
computation techniques and the implication of cooperation between
PCEs.
- Submit a document defining the protocol for communication between
LSRs and PCEs.
- Submit document(s) defining extensions to routing and signalling
protocols necessary to support the use of a PCE model within MPLS
networks.
- Submit a document defining MIB modules for modeling and management
of PCE systems.
--=====================_231100534==_.ALT-- --===============0480077262== 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 --===============0480077262==-- From mailman-bounces@ietf.org Sun Aug 1 05:17: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 FAA04713 for ; Sun, 1 Aug 2004 05:17:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrCVl-0000Kl-Ms for mpls-archive@ietf.org; Sun, 01 Aug 2004 05:20:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrCDM-0003cr-Jp for mpls-archive@ietf.org; Sun, 01 Aug 2004 05:01:08 -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: Sun, 01 Aug 2004 05:00:19 -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 Mon Aug 2 13:08: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 NAA19311; Mon, 2 Aug 2004 13:08:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrgL3-0000MP-N1; Mon, 02 Aug 2004 13:11:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brg5g-0004V2-7j; Mon, 02 Aug 2004 12:55:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brg1o-0002QL-5C for mpls@megatron.ietf.org; Mon, 02 Aug 2004 12:51: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 MAA18217 for ; Mon, 2 Aug 2004 12:51: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 1Brg4f-0008Su-0O for mpls@ietf.org; Mon, 02 Aug 2004 12:54:12 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 02 Aug 2004 12:50:36 -0400 X-BrightmailFiltered: true Received: from cisco.com (lir.cisco.com [161.44.172.144]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i72GoXRK018996 for ; Mon, 2 Aug 2004 12:50:33 -0400 (EDT) Message-Id: <200408021650.i72GoXRK018996@rtp-core-2.cisco.com> To: mpls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; GNU Emacs 21.1.1 Date: Mon, 02 Aug 2004 12:50:35 -0400 From: George Swallow X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [mpls] Presentation Materials 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 Folks - Loa's computer died. Please send me any materials that you sent to Loa only. For those of you still posting please copy both of us. Thanks, ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Aug 2 18:32: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 SAA10904; Mon, 2 Aug 2004 18:32:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrlOt-0005rr-O6; Mon, 02 Aug 2004 18:35:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brl4p-0003Fa-Qa; Mon, 02 Aug 2004 18:14:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brjtk-0007jI-Uf for mpls@megatron.ietf.org; Mon, 02 Aug 2004 16:59:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04987 for ; Mon, 2 Aug 2004 16:59:06 -0400 (EDT) Received: from pollux.ietf60.ietf.org ([130.129.16.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brjwf-0004PO-T5 for mpls@ietf.org; Mon, 02 Aug 2004 17:02:11 -0400 Received: from Puppy (opene-130-129-128-84.ietf60.ietf.org [130.129.128.84]) by pollux.ietf60.ietf.org (8.12.10/8.12.10) with SMTP id i72Kv1aj061713; Mon, 2 Aug 2004 13:57:02 -0700 (PDT) (envelope-from adrian@olddog.co.uk) Message-ID: <005d01c478d3$42e7da20$54808182@Puppy> From: "Adrian Farrel" To: , , "TEWG" Date: Mon, 2 Aug 2004 21:56: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: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: "'Jean Philippe Vasseur'" Subject: [mpls] Agenda and slides for PCE BOF X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Hi, The agenda and slides are on line. http://www.olddog.co.uk/60/pce/pce.ppt Please browse. Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Aug 2 20:56: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 UAA19207; Mon, 2 Aug 2004 20:56:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brne6-0008Qc-Rr; Mon, 02 Aug 2004 20:59:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrnYR-0001en-G2; Mon, 02 Aug 2004 20:53:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrnV3-0007nP-0W for mpls@megatron.ietf.org; Mon, 02 Aug 2004 20:49:53 -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 UAA18898 for ; Mon, 2 Aug 2004 20:49:51 -0400 (EDT) Received: from balavenkata@netscape.net by imo-d02.mx.aol.com (mail_out_v37_r2.6.) id n.19.e0995f0 (22680); Mon, 2 Aug 2004 20:49:15 -0400 (EDT) Received: from netscape.net ([67.50.107.71]) by air-in04.mx.aol.com (v100.26) with ESMTP id MAILININ41-5898410ee10a3c2; Mon, 02 Aug 2004 20:49:15 -0400 Message-ID: <410EE3DA.7090306@netscape.net> Date: Mon, 02 Aug 2004 18:01:14 -0700 From: Bala S Venkata User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org, jvasseur@cisco.com Subject: RE: [mpls] PCE BOF - Thursday August 5, 13:00 to 15:00 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 67.50.107.71 X-Mailer: Unknown (No Version) 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: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit I found the PCE BOF slides here: http://home.clara.net/olddog/60/pce/pce.ppt Are these the ones you mentioned in your email ? >Message: 1 >Date: Sun, 01 Aug 2004 01:07:35 -0400 >From: Jean Philippe Vasseur >Subject: [mpls] PCE BOF - Thursday August 5, 13:00 to 15:00 >To: , , "TEWG" > , >Cc: Bill Fenner >Message-ID: <4.3.2.7.2.20040801005948.06eb6b58@wells.cisco.com> >Content-Type: text/plain; charset="us-ascii" > >Hi, > >Just to let you know that the set of slides for the PCE BOF will be >available next Monday morning (http://www.olddog.co.uk/60/pce.ppt) > >Cheers, > >JP and Adrian. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Aug 2 22:53: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 WAA24036; Mon, 2 Aug 2004 22:53:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrpU0-0001Pr-30; Mon, 02 Aug 2004 22:56:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrpJI-0008E1-5U; Mon, 02 Aug 2004 22:45:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrpFl-0005sh-JH for mpls@megatron.ietf.org; Mon, 02 Aug 2004 22:42: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 WAA23529 for ; Mon, 2 Aug 2004 22:42:11 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrpIj-0001GA-GG for mpls@ietf.org; Mon, 02 Aug 2004 22:45:19 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 02 Aug 2004 19:42:00 -0700 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i732fbau002708; Mon, 2 Aug 2004 19:41:37 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (rtp-vpn3-171.cisco.com [10.82.216.171]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id TAA05422; Mon, 2 Aug 2004 19:41:35 -0700 (PDT) Message-Id: <4.3.2.7.2.20040802224243.04253980@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Aug 2004 22:42:55 -0400 To: Bala S Venkata From: Jean Philippe Vasseur Subject: RE: [mpls] PCE BOF - Thursday August 5, 13:00 to 15:00 In-Reply-To: <410EE3DA.7090306@netscape.net> 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 At 06:01 PM 8/2/2004 -0700, Bala S Venkata wrote: >I found the PCE BOF slides here: > >http://home.clara.net/olddog/60/pce/pce.ppt > >Are these the ones you mentioned in your email ? yes JP. >>Message: 1 >>Date: Sun, 01 Aug 2004 01:07:35 -0400 >>From: Jean Philippe Vasseur >>Subject: [mpls] PCE BOF - Thursday August 5, 13:00 to 15:00 >>To: , , "TEWG" >> , >>Cc: Bill Fenner >>Message-ID: <4.3.2.7.2.20040801005948.06eb6b58@wells.cisco.com> >>Content-Type: text/plain; charset="us-ascii" >> >>Hi, >> >>Just to let you know that the set of slides for the PCE BOF will be >>available next Monday morning (http://www.olddog.co.uk/60/pce.ppt) >> >>Cheers, >> >>JP and Adrian. > > > > >_______________________________________________ >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 Aug 2 23:04: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 XAA24694; Mon, 2 Aug 2004 23:04:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brpdx-0001XO-7W; Mon, 02 Aug 2004 23:07:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrpSG-0002qD-KQ; Mon, 02 Aug 2004 22:55:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrpNB-0000V4-2U for mpls@megatron.ietf.org; Mon, 02 Aug 2004 22:49: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 WAA23842 for ; Mon, 2 Aug 2004 22:49:50 -0400 (EDT) Received: from pollux.ietf60.ietf.org ([130.129.16.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrpQ8-0001Mq-Rs for mpls@ietf.org; Mon, 02 Aug 2004 22:52:58 -0400 Received: from Puppy (opene-130-129-134-83.ietf60.ietf.org [130.129.134.83]) by pollux.ietf60.ietf.org (8.12.10/8.12.10) with SMTP id i732nPaj076585; Mon, 2 Aug 2004 19:49:26 -0700 (PDT) (envelope-from adrian@olddog.co.uk) Message-ID: <011701c47904$7d25b5f0$54808182@Puppy> From: "Adrian Farrel" To: "Bala S Venkata" References: <410EE3DA.7090306@netscape.net> Subject: Re: [mpls] PCE BOF - Thursday August 5, 13:00 to 15:00 Date: Tue, 3 Aug 2004 03:49:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, jvasseur@cisco.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Thanks Bala, Your competence is greater than mine. Adrian ----- Original Message ----- From: "Bala S Venkata" To: ; Sent: Tuesday, August 03, 2004 2:01 AM Subject: RE: [mpls] PCE BOF - Thursday August 5, 13:00 to 15:00 > I found the PCE BOF slides here: > > http://home.clara.net/olddog/60/pce/pce.ppt > > Are these the ones you mentioned in your email ? > > > >Message: 1 > >Date: Sun, 01 Aug 2004 01:07:35 -0400 > >From: Jean Philippe Vasseur > >Subject: [mpls] PCE BOF - Thursday August 5, 13:00 to 15:00 > >To: , , "TEWG" > > , > >Cc: Bill Fenner > >Message-ID: <4.3.2.7.2.20040801005948.06eb6b58@wells.cisco.com> > >Content-Type: text/plain; charset="us-ascii" > > > >Hi, > > > >Just to let you know that the set of slides for the PCE BOF will be > >available next Monday morning (http://www.olddog.co.uk/60/pce.ppt) > > > >Cheers, > > > >JP and Adrian. > > > > > _______________________________________________ > 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 Aug 3 17:16: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 RAA12631; Tue, 3 Aug 2004 17:16:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs6hf-0001bs-1A; Tue, 03 Aug 2004 17:20:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs6ai-00049v-9S; Tue, 03 Aug 2004 17:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs6Vk-0003Sa-Gs for mpls@megatron.ietf.org; Tue, 03 Aug 2004 17:07: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 RAA12088 for ; Tue, 3 Aug 2004 17:07:50 -0400 (EDT) Received: from imo-d01.mx.aol.com ([205.188.157.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs6Yg-0001T1-KX for mpls@ietf.org; Tue, 03 Aug 2004 17:11:07 -0400 Received: from balavenkata@netscape.net by imo-d01.mx.aol.com (mail_out_v37_r3.4.) id v.1b3.b67e9cc (16240); Tue, 3 Aug 2004 17:07:04 -0400 (EDT) Received: from netscape.net ([67.50.107.71]) by air-in03.mx.aol.com (v100.26) with ESMTP id MAILININ34-3f70410ffe77392; Tue, 03 Aug 2004 17:07:04 -0400 Message-ID: <41100149.5050107@netscape.net> Date: Tue, 03 Aug 2004 14:19:05 -0700 From: Bala S Venkata User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel , mpls@ietf.org, jvasseur@cisco.com Subject: Re: [mpls] PCE BOF - Thursday August 5, 13:00 to 15:00 References: <410EE3DA.7090306@netscape.net> <011701c47904$7d25b5f0$54808182@Puppy> In-Reply-To: <011701c47904$7d25b5f0$54808182@Puppy> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 67.50.107.71 X-Mailer: Unknown (No Version) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Thanks Adrian. If fixing a broken link can get me higher 'competence' ratings, I ought to have a talk with my Manager to better my next review :) >Thanks Bala, > >Your competence is greater than mine. > >Adrian > Coming to the PCE BOF slides, 1. I see that in the "Overvew" section (slide 4) there is some reference to PCE, PCS...what did you mean by "PCS (S=Server)-> PCE" ? I have also seen references to PCC and PCS...do they apply only in the context of distributed path calculation ? 2. Is RSVP the only signaling protocol between an LER and a PCE ? Or is it like there are no assumptions made abt the communication between LER and PCE ? (maybe this is my lack of prior knowledge but the draft on PCE signaling "draft-lee-mpls-path-request" mentioned in Slide 26 seems to have expired ??) tx /bala >----- Original Message ----- >From: "Bala S Venkata" >To: ; >Sent: Tuesday, August 03, 2004 2:01 AM >Subject: RE: [mpls] PCE BOF - Thursday August 5, 13:00 to 15:00 > > > > >>I found the PCE BOF slides here: >> >>http://home.clara.net/olddog/60/pce/pce.ppt >> >>Are these the ones you mentioned in your email ? >> >> >> >> _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Aug 3 20:42: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 UAA26513; Tue, 3 Aug 2004 20:42:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs9v7-00057S-0a; Tue, 03 Aug 2004 20:46:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs9kV-0003ID-1j; Tue, 03 Aug 2004 20:35:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs9gk-0002UU-OP for mpls@megatron.ietf.org; Tue, 03 Aug 2004 20:31: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 UAA25757 for ; Tue, 3 Aug 2004 20:31:25 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs9ju-0004t1-NY for mpls@ietf.org; Tue, 03 Aug 2004 20:34:44 -0400 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i740FwLl011942; Tue, 3 Aug 2004 17:15:58 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (rtp-vpn1-571.cisco.com [10.82.226.59]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA08014; Tue, 3 Aug 2004 17:15:57 -0700 (PDT) Message-Id: <4.3.2.7.2.20040803171034.06374ef8@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Aug 2004 17:17:20 -0700 To: Bala S Venkata From: Jean Philippe Vasseur Subject: Re: [mpls] PCE BOF - Thursday August 5, 13:00 to 15:00 In-Reply-To: <41100149.5050107@netscape.net> References: <011701c47904$7d25b5f0$54808182@Puppy> <410EE3DA.7090306@netscape.net> <011701c47904$7d25b5f0$54808182@Puppy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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: e8a67952aa972b528dd04570d58ad8fe At 02:19 PM 8/3/2004 -0700, Bala S Venkata wrote: >Thanks Adrian. If fixing a broken link can get me higher 'competence' >ratings, I ought to have a talk with my Manager to better my next review :) > >>Thanks Bala, >> >>Your competence is greater than mine. >> >>Adrian > >Coming to the PCE BOF slides, > >1. I see that in the "Overvew" section (slide 4) there is some reference to >PCE, PCS...what did you mean by "PCS (S=Server)-> PCE" ? I have also >seen references to PCC and PCS...do they apply only in the context of >distributed path calculation ? PCS is the old terminology, this is what I'll explain here. >2. Is RSVP the only signaling protocol between an LER and a PCE ? Or >is it like there are no assumptions made abt the communication between >LER and PCE ? (maybe this is my lack of prior knowledge but the draft >on PCE signaling "draft-lee-mpls-path-request" mentioned in Slide 26 >seems to have expired ??) The purpose of the BOF are listed in slides 39, not to discuss possible solutions. To specifically answer your question, there is one draft proposing to use RSVP between an LSR and the PCE, but this is one solution, there are other proposed alternatives. JP. >tx > >/bala > >>----- Original Message ----- From: "Bala S Venkata" >> >>To: ; >>Sent: Tuesday, August 03, 2004 2:01 AM >>Subject: RE: [mpls] PCE BOF - Thursday August 5, 13:00 to 15:00 >> >> >> >> >>>I found the PCE BOF slides here: >>> >>>http://home.clara.net/olddog/60/pce/pce.ppt >>> >>>Are these the ones you mentioned in your email ? >>> >>> >>> > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Aug 5 04:30: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 EAA03517; Thu, 5 Aug 2004 04:30:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bsdhh-0002T1-Sw; Thu, 05 Aug 2004 04:34:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsdc4-00006e-HO; Thu, 05 Aug 2004 04:28:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsWVs-0002bt-0p; Wed, 04 Aug 2004 20:53: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 UAA25242; Wed, 4 Aug 2004 20:53:42 -0400 (EDT) Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsWZB-0004CE-H6; Wed, 04 Aug 2004 20:57:14 -0400 Received: from l04955 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0I1Y00BEI7PCTB@mta0.huawei.com>; Thu, 05 Aug 2004 08:51:13 +0800 (CST) Date: Thu, 05 Aug 2004 08:53:27 +0800 From: lidefeng <77cronux.leed0621@huawei.com> To: Jean Philippe Vasseur , ccamp@ops.ietf.org, mpls@ietf.org, TEWG , rtgwg@ietf.org Message-id: <001601c47a86$9f0619c0$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com References: <4.3.2.7.2.20040801005948.06eb6b58@wells.cisco.com> X-Spam-Score: 1.0 (+) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 X-Mailman-Approved-At: Thu, 05 Aug 2004 04:28:34 -0400 Cc: Bill Fenner Subject: [mpls] Re: PCE BOF - Thursday August 5, 13:00 to 15: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: , Content-Type: multipart/mixed; boundary="===============0473407688==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 This is a multi-part message in MIME format. --===============0473407688== Content-type: multipart/alternative; boundary="Boundary_(ID_XSq70ce5aSKHw2MdqPAPQQ)" This is a multi-part message in MIME format. --Boundary_(ID_XSq70ce5aSKHw2MdqPAPQQ) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Hi, I think it is very necessary to do this work in IETF, Service Providers in China also expressed such requirements during the technical exchanges. I have delved into PCE.ppt in the link, however, I can't find the following drafts, If anyone can share with me? Could you please send me these drafts in e-mail, Thanks! draft-mescal-pce-interas-00.txt draft-mescal-pcp-interas-00.txt draft-mescal-pceid-00.txt Best Regards Defeng Li ----- Original Message ----- From: Jean Philippe Vasseur To: ccamp@ops.ietf.org ; mpls@ietf.org ; TEWG ; rtgwg@ietf.org Cc: adrian@olddog.co.uk ; zinin@psg.com ; Bill Fenner Sent: Sunday, August 01, 2004 1:07 PM Subject: PCE BOF - Thursday August 5, 13:00 to 15:00 Hi, Just to let you know that the set of slides for the PCE BOF will be available next Monday morning (http://www.olddog.co.uk/60/pce.ppt) Cheers, JP and Adrian. Path Computation Element BOF (PCE BOF) 60th IETF, San Diego, August 2004 Routing Area Ads: Alex Zinin (zinin@psg.com), Bill Fenner (fenner@research.att.com) BOF Chairs: JP Vasseur (jvasseur@cisco.com), Adrian Farrel (adrian@olddog.co.uk) Description: In certain MPLS TE networks it may be beneficial or desirable to have path computation performed by a distinct node (termed the Path Computation Element PCE) that is not the LSR that needs to know the path. This BOF examines the scope of such function, what extensions to existing protocols might required, what additional protocols may need to be developed, and whether there is cuase and support for this work within the IETF. Proposed WG Charter Organizational Overview The PCE working group coordinates the work within the IETF of defining the operation of path computation elements within the Internet. Path computation elements are responsible for computing paths through IP networks for uses such as traffic engineering so that a prime consumer of such paths might be an MPLS-TE LSR. Areas of responsibility will include the collection of attributes relevant to the computation of paths, the discovery by LSRs of available path computation elements, the communication with LSRs for the request of path computation, the collaboration between path computation elements within the network, and analysis of path computation algorithms with a view to ensuring consistency between computed paths. The working group will work closely with many working groups in the Routing Area including the OSPF, IS-IS, IDR, MPLS and CCAMP working groups. Working Group Scope The PCE working group scope includes: - Definition of Generalized Traffic Engineered LSP paths computation techniques involving Path Computation Element(s). This includes the intra IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path computation for Point-to-Point, Point-to-Multipoint and Multipoint-to-Multipoint TE LSPs. - Definition of protocol-independent metrics and constraints defining path quality measurement criteria, algorithm complexity and scalability criteria related to path computation techniques. - Definition of requirements for communication between LSRs and PCEs including routing extensions in support of PCE discovery techniques within an IGP area and across multiple IGP areas, ASes and Provider networks, and including the development of new protocols or protocol extensions for requesting path computation and supplying responses. Any protocol extensions will developed in conjunction with the working groups in charge of the specific protocols. - Specification of routing (OSPF, ISIS, BGP) and signalling extensions (RSVP-TE) required by PCE-based path computation techniques. The extensions will developed in conjunction with the working groups in charge of the specific protocols. - Specification of requirements and protocol extensions related to the policy, security and confidentiality aspects of PCE-based path computation techniques involving PCEs of multiple Providers. - Definition of MIBs, management procedures related to the protocol extensions defined by the WG In doing this work, the WG will closely work with at least the following other WGs: CCAMP, MPLS, ISIS, OSPF, IDR. The WG will also cooperate with the ITU-T and OIF. Goals and Milestones Dates for milestones to be decided later. - Post strawman WG goals and charter. - Submit WG document defining the framework and applicability of the PCE model. - Select a single candidate protocol from communication between LSRs and PCEs. - Submit document(s) that define various path computation models - Submit an analysis document examining the requirements for coherent computation techniques and the implication of cooperation between PCEs. - Submit a document defining the protocol for communication between LSRs and PCEs. - Submit document(s) defining extensions to routing and signalling protocols necessary to support the use of a PCE model within MPLS networks. - Submit a document defining MIB modules for modeling and management of PCE systems. --Boundary_(ID_XSq70ce5aSKHw2MdqPAPQQ) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: 7BIT
Hi,
 
I think it is very necessary to do this work in IETF, Service Providers in China also expressed such requirements during the technical exchanges.
 
I have delved into PCE.ppt in the link, however, I can't find the following drafts, If anyone can share with me? Could you please send me these drafts in e-mail, Thanks!
 
draft-mescal-pce-interas-00.txt
draft-mescal-pcp-interas-00.txt
draft-mescal-pceid-00.txt
 
Best Regards
Defeng Li 
----- Original Message -----
Sent: Sunday, August 01, 2004 1:07 PM
Subject: PCE BOF - Thursday August 5, 13:00 to 15:00

Hi,

Just to let you know that the set of slides for the PCE BOF will be available next Monday morning (http://www.olddog.co.uk/60/pce.ppt)

Cheers,

JP and Adrian.

Path Computation Element BOF (PCE BOF)
60th IETF, San Diego, August 2004

Routing Area Ads: Alex Zinin (zinin@psg.com),
Bill Fenner (fenner@research.att.com)

BOF Chairs: JP Vasseur (jvasseur@cisco.com), Adrian Farrel (adrian@olddog.co.uk)

Description:
In certain MPLS TE networks it may be beneficial or desirable to have path
computation performed by a distinct node (termed the Path Computation
Element PCE) that is not the LSR that needs to know the path. This BOF
examines the scope of such function, what extensions to existing protocols
might required, what additional protocols may need to be developed, and
whether there is cuase and support for this work within the IETF.

Proposed WG Charter

Organizational Overview
The PCE working group coordinates the work within the IETF of defining the
operation of path computation elements within the Internet. Path
computation elements are responsible for computing paths through IP
networks for uses such as traffic engineering so that a prime consumer of
such paths might be an MPLS-TE LSR. Areas of responsibility will include
the collection of attributes relevant to the computation of paths, the
discovery by LSRs of available path computation elements, the communication
with LSRs for the request of path computation, the collaboration between
path computation elements within the network, and analysis of path
computation algorithms with a view to ensuring consistency between computed
paths. The working group will work closely with many working groups in the
Routing Area including the OSPF, IS-IS, IDR, MPLS and CCAMP working groups.

Working Group Scope

The PCE working group scope includes:
- Definition of Generalized Traffic Engineered LSP paths computation
techniques involving Path Computation Element(s). This includes the intra
IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path
computation for Point-to-Point, Point-to-Multipoint and
Multipoint-to-Multipoint TE LSPs.
- Definition of protocol-independent metrics and constraints defining path
quality measurement criteria, algorithm complexity and scalability criteria
related to path computation techniques.
- Definition of requirements for communication between LSRs and PCEs
including routing extensions in support of PCE discovery techniques within
an IGP area and across multiple IGP areas, ASes and Provider networks, and
including the development of new protocols or protocol extensions for
requesting path computation and supplying responses. Any protocol
extensions will developed in conjunction with the working groups in charge
of the specific protocols.
- Specification of routing (OSPF, ISIS, BGP) and signalling extensions
(RSVP-TE) required by PCE-based path computation techniques. The extensions
will developed in conjunction with the working groups in charge of the
specific protocols.
- Specification of requirements and protocol extensions related to the
policy, security and confidentiality aspects of PCE-based path computation
techniques involving PCEs of multiple Providers.
- Definition of MIBs, management procedures related to the protocol
extensions defined by the WG
In doing this work, the WG will closely work with at least the following
other WGs: CCAMP, MPLS, ISIS, OSPF, IDR. The WG will also cooperate with
the ITU-T and OIF.

Goals and Milestones
Dates for milestones to be decided later.
- Post strawman WG goals and charter.
- Submit WG document defining the framework and applicability of the
PCE model.
- Select a single candidate protocol from communication between LSRs
and PCEs.
- Submit document(s) that define various path computation models
- Submit an analysis document examining the requirements for coherent
computation techniques and the implication of cooperation between
PCEs.
- Submit a document defining the protocol for communication between
LSRs and PCEs.
- Submit document(s) defining extensions to routing and signalling
protocols necessary to support the use of a PCE model within MPLS
networks.
- Submit a document defining MIB modules for modeling and management
of PCE systems.
--Boundary_(ID_XSq70ce5aSKHw2MdqPAPQQ)-- --===============0473407688== 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 --===============0473407688==-- From mpls-bounces@ietf.org Thu Aug 5 13:04: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 NAA00173; Thu, 5 Aug 2004 13:04:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bslj4-0001Cb-OL; Thu, 05 Aug 2004 13:08:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BslWa-0002tM-6b; Thu, 05 Aug 2004 12:55:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BslVl-0002a5-LZ; Thu, 05 Aug 2004 12:54: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 MAA29654; Thu, 5 Aug 2004 12:54:34 -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 1BslZI-00011w-3y; Thu, 05 Aug 2004 12:58:16 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 05 Aug 2004 09:56:42 +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 i75Grsna022976; Thu, 5 Aug 2004 09:53:55 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (rtp-vpn1-285.cisco.com [10.82.225.29]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA04319; Thu, 5 Aug 2004 09:53:51 -0700 (PDT) Message-Id: <4.3.2.7.2.20040805094640.06bd33f8@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Aug 2004 09:53:47 -0700 To: lidefeng <77cronux.leed0621@huawei.com> From: Jean Philippe Vasseur In-Reply-To: <001601c47a86$9f0619c0$07436e0a@HUAWEI.COM> References: <4.3.2.7.2.20040801005948.06eb6b58@wells.cisco.com> Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Cc: ccamp@ops.ietf.org, mpls@ietf.org, TEWG , Bill Fenner , rtgwg@ietf.org Subject: [mpls] Re: PCE BOF - Thursday August 5, 13:00 to 15: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: , Content-Type: multipart/mixed; boundary="===============1096255722==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 --===============1096255722== Content-Type: multipart/alternative; boundary="=====================_94041604==_.ALT" --=====================_94041604==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, At 08:53 AM 8/5/2004 +0800, lidefeng wrote: >Hi, > >I think it is very necessary to do this work in IETF, Service Providers in >China also expressed such requirements during the technical exchanges. Thanks for the feed-back, feel free to join the BOF. > >I have delved into PCE.ppt in the link, however, I can't find the >following drafts, If anyone can share with me? Could you please send me >these drafts in e-mail, Thanks! > >draft-mescal-pce-interas-00.txt >draft-mescal-pcp-interas-00.txt >draft-mescal-pceid-00.txt Those drafts falls in the "Under Work" category ... and have not been published yet. I'll say a few words about them this afternoon, the goal was just to highlight on-going work related to this area. JP. > >Best Regards >Defeng Li >----- Original Message ----- >From: Jean Philippe Vasseur >To: ccamp@ops.ietf.org ; >mpls@ietf.org ; TEWG ; >rtgwg@ietf.org >Cc: adrian@olddog.co.uk ; >zinin@psg.com ; Bill >Fenner >Sent: Sunday, August 01, 2004 1:07 PM >Subject: PCE BOF - Thursday August 5, 13:00 to 15:00 > >Hi, > >Just to let you know that the set of slides for the PCE BOF will be >available next Monday morning (http://www.olddog.co.uk/60/pce.ppt) > >Cheers, > >JP and Adrian. > >Path Computation Element BOF (PCE BOF) >60th IETF, San Diego, August 2004 > >Routing Area Ads: Alex Zinin (zinin@psg.com), >Bill Fenner (fenner@research.att.com) > >BOF Chairs: JP Vasseur (jvasseur@cisco.com), >Adrian Farrel (adrian@olddog.co.uk) > >Description: >In certain MPLS TE networks it may be beneficial or desirable to have path >computation performed by a distinct node (termed the Path Computation >Element PCE) that is not the LSR that needs to know the path. This BOF >examines the scope of such function, what extensions to existing protocols >might required, what additional protocols may need to be developed, and >whether there is cuase and support for this work within the IETF. > >Proposed WG Charter > >Organizational Overview >The PCE working group coordinates the work within the IETF of defining the >operation of path computation elements within the Internet. Path >computation elements are responsible for computing paths through IP >networks for uses such as traffic engineering so that a prime consumer of >such paths might be an MPLS-TE LSR. Areas of responsibility will include >the collection of attributes relevant to the computation of paths, the >discovery by LSRs of available path computation elements, the communication >with LSRs for the request of path computation, the collaboration between >path computation elements within the network, and analysis of path >computation algorithms with a view to ensuring consistency between computed >paths. The working group will work closely with many working groups in the >Routing Area including the OSPF, IS-IS, IDR, MPLS and CCAMP working groups. > >Working Group Scope > >The PCE working group scope includes: >- Definition of Generalized Traffic Engineered LSP paths computation >techniques involving Path Computation Element(s). This includes the intra >IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path >computation for Point-to-Point, Point-to-Multipoint and >Multipoint-to-Multipoint TE LSPs. >- Definition of protocol-independent metrics and constraints defining path >quality measurement criteria, algorithm complexity and scalability criteria >related to path computation techniques. >- Definition of requirements for communication between LSRs and PCEs >including routing extensions in support of PCE discovery techniques within >an IGP area and across multiple IGP areas, ASes and Provider networks, and >including the development of new protocols or protocol extensions for >requesting path computation and supplying responses. Any protocol >extensions will developed in conjunction with the working groups in charge >of the specific protocols. >- Specification of routing (OSPF, ISIS, BGP) and signalling extensions >(RSVP-TE) required by PCE-based path computation techniques. The extensions >will developed in conjunction with the working groups in charge of the >specific protocols. >- Specification of requirements and protocol extensions related to the >policy, security and confidentiality aspects of PCE-based path computation >techniques involving PCEs of multiple Providers. >- Definition of MIBs, management procedures related to the protocol >extensions defined by the WG >In doing this work, the WG will closely work with at least the following >other WGs: CCAMP, MPLS, ISIS, OSPF, IDR. The WG will also cooperate with >the ITU-T and OIF. > >Goals and Milestones >Dates for milestones to be decided later. >- Post strawman WG goals and charter. >- Submit WG document defining the framework and applicability of the >PCE model. >- Select a single candidate protocol from communication between LSRs >and PCEs. >- Submit document(s) that define various path computation models >- Submit an analysis document examining the requirements for coherent >computation techniques and the implication of cooperation between >PCEs. >- Submit a document defining the protocol for communication between >LSRs and PCEs. >- Submit document(s) defining extensions to routing and signalling >protocols necessary to support the use of a PCE model within MPLS >networks. >- Submit a document defining MIB modules for modeling and management >of PCE systems. --=====================_94041604==_.ALT Content-Type: text/html; charset="us-ascii" Hi,

At 08:53 AM 8/5/2004 +0800, lidefeng wrote:
Hi,
 
I think it is very necessary to do this work in IETF, Service Providers in China also expressed such requirements during the technical exchanges.

Thanks for the feed-back, feel free to join the BOF.

 
I have delved into PCE.ppt in the link, however, I can't find the following drafts, If anyone can share with me? Could you please send me these drafts in e-mail, Thanks!
 
draft-mescal-pce-interas-00.txt
draft-mescal-pcp-interas-00.txt
draft-mescal-pceid-00.txt

Those drafts falls in the "Under Work" category ... and have not been published yet. I'll say a few words about them this afternoon, the goal was just to highlight on-going work related to this area.

JP.

 
Best Regards
Defeng Li
----- Original Message -----
From: Jean Philippe Vasseur
To: ccamp@ops.ietf.org ; mpls@ietf.org ; TEWG ; rtgwg@ietf.org
Cc: adrian@olddog.co.uk ; zinin@psg.com ; Bill Fenner
Sent: Sunday, August 01, 2004 1:07 PM
Subject: PCE BOF - Thursday August 5, 13:00 to 15:00

Hi,

Just to let you know that the set of slides for the PCE BOF will be available next Monday morning (http://www.olddog.co.uk/60/pce.ppt)

Cheers,

JP and Adrian.

Path Computation Element BOF (PCE BOF)
60th IETF, San Diego, August 2004

Routing Area Ads: Alex Zinin (zinin@psg.com),
Bill Fenner (fenner@research.att.com)

BOF Chairs: JP Vasseur (jvasseur@cisco.com), Adrian Farrel (adrian@olddog.co.uk)

Description:
In certain MPLS TE networks it may be beneficial or desirable to have path
computation performed by a distinct node (termed the Path Computation
Element PCE) that is not the LSR that needs to know the path. This BOF
examines the scope of such function, what extensions to existing protocols
might required, what additional protocols may need to be developed, and
whether there is cuase and support for this work within the IETF.

Proposed WG Charter

Organizational Overview
The PCE working group coordinates the work within the IETF of defining the
operation of path computation elements within the Internet. Path
computation elements are responsible for computing paths through IP
networks for uses such as traffic engineering so that a prime consumer of
such paths might be an MPLS-TE LSR. Areas of responsibility will include
the collection of attributes relevant to the computation of paths, the
discovery by LSRs of available path computation elements, the communication
with LSRs for the request of path computation, the collaboration between
path computation elements within the network, and analysis of path
computation algorithms with a view to ensuring consistency between computed
paths. The working group will work closely with many working groups in the
Routing Area including the OSPF, IS-IS, IDR, MPLS and CCAMP working groups.

Working Group Scope

The PCE working group scope includes:
- Definition of Generalized Traffic Engineered LSP paths computation
techniques involving Path Computation Element(s). This includes the intra
IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path
computation for Point-to-Point, Point-to-Multipoint and
Multipoint-to-Multipoint TE LSPs.
- Definition of protocol-independent metrics and constraints defining path
quality measurement criteria, algorithm complexity and scalability criteria
related to path computation techniques.
- Definition of requirements for communication between LSRs and PCEs
including routing extensions in support of PCE discovery techniques within
an IGP area and across multiple IGP areas, ASes and Provider networks, and
including the development of new protocols or protocol extensions for
requesting path computation and supplying responses. Any protocol
extensions will developed in conjunction with the working groups in charge
of the specific protocols.
- Specification of routing (OSPF, ISIS, BGP) and signalling extensions
(RSVP-TE) required by PCE-based path computation techniques. The extensions
will developed in conjunction with the working groups in charge of the
specific protocols.
- Specification of requirements and protocol extensions related to the
policy, security and confidentiality aspects of PCE-based path computation
techniques involving PCEs of multiple Providers.
- Definition of MIBs, management procedures related to the protocol
extensions defined by the WG
In doing this work, the WG will closely work with at least the following
other WGs: CCAMP, MPLS, ISIS, OSPF, IDR. The WG will also cooperate with
the ITU-T and OIF.

Goals and Milestones
Dates for milestones to be decided later.
- Post strawman WG goals and charter.
- Submit WG document defining the framework and applicability of the
PCE model.
- Select a single candidate protocol from communication between LSRs
and PCEs.
- Submit document(s) that define various path computation models
- Submit an analysis document examining the requirements for coherent
computation techniques and the implication of cooperation between
PCEs.
- Submit a document defining the protocol for communication between
LSRs and PCEs.
- Submit document(s) defining extensions to routing and signalling
protocols necessary to support the use of a PCE model within MPLS
networks.
- Submit a document defining MIB modules for modeling and management
of PCE systems.
--=====================_94041604==_.ALT-- --===============1096255722== 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 --===============1096255722==-- From mpls-bounces@ietf.org Thu Aug 5 18:12: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 SAA20354; Thu, 5 Aug 2004 18:12:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsqXD-0006KP-M3; Thu, 05 Aug 2004 18:16:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsqIo-0002Wh-Lq; Thu, 05 Aug 2004 18:01:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsqCn-0000Td-31 for mpls@megatron.ietf.org; Thu, 05 Aug 2004 17:55: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 RAA18327 for ; Thu, 5 Aug 2004 17:55:18 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsqGL-0005vw-Ow for mpls@ietf.org; Thu, 05 Aug 2004 17:59:03 -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 i75Lov911833; Thu, 5 Aug 2004 14:50:57 -0700 (PDT) (envelope-from rahul@juniper.net) Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i75Loqe83989; Thu, 5 Aug 2004 14:50:52 -0700 (PDT) (envelope-from rahul@juniper.net) Received: from localhost (rahul@localhost) by sapphire.juniper.net (8.11.6/8.11.3) with ESMTP id i75LopW77368; Thu, 5 Aug 2004 14:50:51 -0700 (PDT) (envelope-from rahul@juniper.net) X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs Date: Thu, 5 Aug 2004 14:50:51 -0700 (PDT) From: Rahul Aggarwal To: swallow@cisco.com, "" Message-ID: <20040805144454.D76578@sapphire.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: mpls@ietf.org Subject: [mpls] Re: draft-raggarwa-mpls-rsvp-te-p2mp-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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Hi George and Loa, The authors of draft-raggarwa-mpls-rsvp-te-p2mp-00.txt would like to request it to become a WG document. Thanks, rahul _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Aug 6 15:58: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 PAA21932; Fri, 6 Aug 2004 15:58:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BtAuW-0004IX-LI; Fri, 06 Aug 2004 16:01:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtAlY-0004bU-RI; Fri, 06 Aug 2004 15:52:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtAfS-0003bV-ME for mpls@megatron.ietf.org; Fri, 06 Aug 2004 15:46: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 PAA21218 for ; Fri, 6 Aug 2004 15:46:17 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BtAjB-0003xS-7L for mpls@ietf.org; Fri, 06 Aug 2004 15:50:12 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 06 Aug 2004 15:45:44 -0400 X-BrightmailFiltered: true Received: from zaliw2k01 (che-vpn-cluster-2-36.cisco.com [10.86.242.36]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i76JjeL3010126; Fri, 6 Aug 2004 15:45:41 -0400 (EDT) From: "zafar ali" To: "'Rahul Aggarwal'" , , Subject: RE: [mpls] Re: draft-raggarwa-mpls-rsvp-te-p2mp-00.txt Date: Fri, 6 Aug 2004 15:45:40 -0400 Organization: Cisco Systems Message-ID: <002b01c47bed$f5258940$0200a8c0@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.5709 In-Reply-To: <20040805144454.D76578@sapphire.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Hi Rahul, et al During the WG meeting, there were a number of major comments were made on the requirement document. Given this, I don't think we have a case for adapting solution document by the WG. Thanks Regards... Zafar >-----Original Message----- >From: mpls-bounces@lists.ietf.org >[mailto:mpls-bounces@lists.ietf.org] On Behalf Of Rahul Aggarwal >Sent: Thursday, August 05, 2004 5:51 PM >To: swallow@cisco.com; loa@pi.se >Cc: mpls@ietf.org >Subject: [mpls] Re: draft-raggarwa-mpls-rsvp-te-p2mp-00.txt > > > >Hi George and Loa, > >The authors of draft-raggarwa-mpls-rsvp-te-p2mp-00.txt would >like to request it to become a WG document. > >Thanks, >rahul > >_______________________________________________ >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 Aug 6 16:13: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 QAA22862; Fri, 6 Aug 2004 16:13:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BtB94-0004ZD-KX; Fri, 06 Aug 2004 16:16:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtB0A-000077-05; Fri, 06 Aug 2004 16:07:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtAzV-0008NH-C0 for mpls@megatron.ietf.org; Fri, 06 Aug 2004 16:07: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 QAA22614 for ; Fri, 6 Aug 2004 16:06:59 -0400 (EDT) Received: from natint2.juniper.net ([207.17.136.150] helo=kummer.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BtB3F-0004Tp-Ug for mpls@ietf.org; Fri, 06 Aug 2004 16:10:55 -0400 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id i76K4R0g012983; Fri, 6 Aug 2004 13:04:27 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id i76K4R6h012980; Fri, 6 Aug 2004 13:04:27 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Fri, 6 Aug 2004 13:04:27 -0700 (PDT) From: Kireeti Kompella To: zafar ali Subject: RE: [mpls] Re: draft-raggarwa-mpls-rsvp-te-p2mp-00.txt In-Reply-To: <002b01c47bed$f5258940$0200a8c0@amer.cisco.com> Message-ID: <20040806130339.Y12684@kummer.juniper.net> References: <002b01c47bed$f5258940$0200a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 On Fri, 6 Aug 2004, zafar ali wrote: > Hi Rahul, et al > > During the WG meeting, there were a number of major comments were made on > the requirement document. Given this, I don't think we have a case for > adapting solution document by the WG. The two are orthogonal. I support making draft-raggarwa-mpls-rsvp-te-p2mp-00.txt an MPLS WG doc. > Thanks > > Regards... Zafar > > >-----Original Message----- > >From: mpls-bounces@lists.ietf.org > >[mailto:mpls-bounces@lists.ietf.org] On Behalf Of Rahul Aggarwal > >Sent: Thursday, August 05, 2004 5:51 PM > >To: swallow@cisco.com; loa@pi.se > >Cc: mpls@ietf.org > >Subject: [mpls] Re: draft-raggarwa-mpls-rsvp-te-p2mp-00.txt > > > > > > > >Hi George and Loa, > > > >The authors of draft-raggarwa-mpls-rsvp-te-p2mp-00.txt would > >like to request it to become a WG document. > > > >Thanks, > >rahul > > > >_______________________________________________ > >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 > Kireeti. ------- _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Aug 6 17:36: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 RAA26504; Fri, 6 Aug 2004 17:36:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BtCRX-0005jT-B1; Fri, 06 Aug 2004 17:40:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtCCW-0004I2-1s; Fri, 06 Aug 2004 17:24:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtCB7-00040B-1j for mpls@megatron.ietf.org; Fri, 06 Aug 2004 17:23: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 RAA26091 for ; Fri, 6 Aug 2004 17:23:02 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BtCEt-0005ZN-GN for mpls@ietf.org; Fri, 06 Aug 2004 17:26:59 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 06 Aug 2004 17:30:28 -0400 X-BrightmailFiltered: true Received: from zaliw2k01 (che-vpn-cluster-2-36.cisco.com [10.86.242.36]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i76LMUL3002492; Fri, 6 Aug 2004 17:22:31 -0400 (EDT) From: "zafar ali" To: "'Kireeti Kompella'" Subject: RE: [mpls] Re: draft-raggarwa-mpls-rsvp-te-p2mp-00.txt Date: Fri, 6 Aug 2004 17:22:29 -0400 Organization: Cisco Systems Message-ID: <000001c47bfb$7bdfd190$0200a8c0@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.5709 Importance: Normal In-Reply-To: <20040806130339.Y12684@kummer.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit >-----Original Message----- >From: mpls-bounces@lists.ietf.org >[mailto:mpls-bounces@lists.ietf.org] On Behalf Of Kireeti Kompella >Sent: Friday, August 06, 2004 4:04 PM >To: zafar ali >Cc: mpls@ietf.org >Subject: RE: [mpls] Re: draft-raggarwa-mpls-rsvp-te-p2mp-00.txt > > >On Fri, 6 Aug 2004, zafar ali wrote: > >> Hi Rahul, et al >> >> During the WG meeting, there were a number of major comments >were made >> on the requirement document. Given this, I don't think we >have a case >> for adapting solution document by the WG. > >The two are orthogonal. > Hi Kireeti, How can a solution document be orthogonal to the requirement document, or did I miss something (hidden)? Thanks Regards... Zafar >I support making draft-raggarwa-mpls-rsvp-te-p2mp-00.txt an >MPLS WG doc. > >> Thanks >> >> Regards... Zafar >> >> >-----Original Message----- >> >From: mpls-bounces@lists.ietf.org >> >[mailto:mpls-bounces@lists.ietf.org] On Behalf Of Rahul Aggarwal >> >Sent: Thursday, August 05, 2004 5:51 PM >> >To: swallow@cisco.com; loa@pi.se >> >Cc: mpls@ietf.org >> >Subject: [mpls] Re: draft-raggarwa-mpls-rsvp-te-p2mp-00.txt >> > >> > >> > >> >Hi George and Loa, >> > >> >The authors of draft-raggarwa-mpls-rsvp-te-p2mp-00.txt >would like to >> >request it to become a WG document. >> > >> >Thanks, >> >rahul >> > >> >_______________________________________________ >> >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 >> > >Kireeti. >------- > >_______________________________________________ >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 Aug 9 04:44:21 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 EAA13235; Mon, 9 Aug 2004 04:44:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bu5pp-0000lM-V5; Mon, 09 Aug 2004 04:48:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bu5gt-0003WD-64; Mon, 09 Aug 2004 04:39:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bu5fK-0003RF-41; Mon, 09 Aug 2004 04:38: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 EAA12998; Mon, 9 Aug 2004 04:37:55 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bu5jY-0000hJ-UA; Mon, 09 Aug 2004 04:42:24 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Aug 2004 10:37:46 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Mon, 9 Aug 2004 10:37:44 +0200 Message-ID: <6CF039C5B32037498B02251E11CDE6B019D37E@ftrdmel3.rd.francetelecom.fr> Thread-Topic: PCE BOF - Thursday August 5, 13:00 to 15:00 Thread-Index: AcR6h4rVl65YIZuxT9GHVuELDYITIQDZEP0g From: "BOUCADAIR Mohamed RD-CORE-CAE" To: "lidefeng" <77cronux.leed0621@huawei.com>, "Jean Philippe Vasseur" , , , "TEWG" , X-OriginalArrivalTime: 09 Aug 2004 08:37:46.0037 (UTC) FILETIME=[2509CE50:01C47DEC] X-Spam-Score: 0.6 (/) X-Scan-Signature: ea36de7a5e28e9b4461c8d685f4e97f1 Cc: Bill Fenner Subject: [mpls] RE: PCE BOF - Thursday August 5, 13:00 to 15: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: , Content-Type: multipart/mixed; boundary="===============0994592947==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 6e8a3b85ef670172081194f0b0f68e6f This is a multi-part message in MIME format. --===============0994592947== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47DEC.24650716" This is a multi-part message in MIME format. ------_=_NextPart_001_01C47DEC.24650716 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi,=20 =20 The=20 =20 draft-mescal-pce-interas-00.txt draft-mescal-pcp-interas-00.txt draft-mescal-pceid-00.txt =20 drafts are work in progress. Further information about related work = could be found in www.mescal.org. =20 Best regards, =20 Mohamed -----Message d'origine----- De : owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]De la = part de lidefeng Envoy=A8=A6 : jeudi 5 ao?t 2004 02:53 =A8=A4 : Jean Philippe Vasseur; ccamp@ops.ietf.org; mpls@ietf.org; TEWG; = rtgwg@ietf.org Cc : adrian@olddog.co.uk; zinin@psg.com; Bill Fenner Objet : Re: PCE BOF - Thursday August 5, 13:00 to 15:00 Hi, =20 I think it is very necessary to do this work in IETF, Service Providers = in China also expressed such requirements during the technical = exchanges. =20 I have delved into PCE.ppt in the link, however, I can't find the = following drafts, If anyone can share with me? Could you please send me = these drafts in e-mail, Thanks! =20 draft-mescal-pce-interas-00.txt draft-mescal-pcp-interas-00.txt draft-mescal-pceid-00.txt =20 Best Regards Defeng Li=20 ----- Original Message -----=20 From: Jean Philippe Vasseur=20 To: ccamp@ops.ietf.org ; mpls@ietf.org ; TEWG = ; rtgwg@ietf.org=20 Cc: adrian@olddog.co.uk ; zinin@psg.com ; Bill = Fenner=20 Sent: Sunday, August 01, 2004 1:07 PM Subject: PCE BOF - Thursday August 5, 13:00 to 15:00 Hi, Just to let you know that the set of slides for the PCE BOF will be = available next Monday morning ( = http://www.olddog.co.uk/60/pce.ppt) Cheers, JP and Adrian. Path Computation Element BOF (PCE BOF)=20 60th IETF, San Diego, August 2004 Routing Area Ads: Alex Zinin ( zinin@psg.com),=20 Bill Fenner ( fenner@research.att.com) BOF Chairs: JP Vasseur ( jvasseur@cisco.com), Adrian Farrel ( = adrian@olddog.co.uk) Description:=20 In certain MPLS TE networks it may be beneficial or desirable to have = path=20 computation performed by a distinct node (termed the Path Computation=20 Element PCE) that is not the LSR that needs to know the path. This BOF=20 examines the scope of such function, what extensions to existing = protocols=20 might required, what additional protocols may need to be developed, and=20 whether there is cuase and support for this work within the IETF.=20 Proposed WG Charter=20 Organizational Overview=20 The PCE working group coordinates the work within the IETF of defining = the=20 operation of path computation elements within the Internet. Path=20 computation elements are responsible for computing paths through IP=20 networks for uses such as traffic engineering so that a prime consumer = of=20 such paths might be an MPLS-TE LSR. Areas of responsibility will include = the collection of attributes relevant to the computation of paths, the=20 discovery by LSRs of available path computation elements, the = communication=20 with LSRs for the request of path computation, the collaboration between = path computation elements within the network, and analysis of path=20 computation algorithms with a view to ensuring consistency between = computed=20 paths. The working group will work closely with many working groups in = the=20 Routing Area including the OSPF, IS-IS, IDR, MPLS and CCAMP working = groups.=20 Working Group Scope=20 The PCE working group scope includes:=20 - Definition of Generalized Traffic Engineered LSP paths computation=20 techniques involving Path Computation Element(s). This includes the = intra=20 IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path=20 computation for Point-to-Point, Point-to-Multipoint and=20 Multipoint-to-Multipoint TE LSPs.=20 - Definition of protocol-independent metrics and constraints defining = path=20 quality measurement criteria, algorithm complexity and scalability = criteria=20 related to path computation techniques.=20 - Definition of requirements for communication between LSRs and PCEs=20 including routing extensions in support of PCE discovery techniques = within=20 an IGP area and across multiple IGP areas, ASes and Provider networks, = and=20 including the development of new protocols or protocol extensions for=20 requesting path computation and supplying responses. Any protocol=20 extensions will developed in conjunction with the working groups in = charge=20 of the specific protocols.=20 - Specification of routing (OSPF, ISIS, BGP) and signalling extensions=20 (RSVP-TE) required by PCE-based path computation techniques. The = extensions=20 will developed in conjunction with the working groups in charge of the=20 specific protocols.=20 - Specification of requirements and protocol extensions related to the=20 policy, security and confidentiality aspects of PCE-based path = computation=20 techniques involving PCEs of multiple Providers.=20 - Definition of MIBs, management procedures related to the protocol=20 extensions defined by the WG=20 In doing this work, the WG will closely work with at least the following = other WGs: CCAMP, MPLS, ISIS, OSPF, IDR. The WG will also cooperate with = the ITU-T and OIF.=20 Goals and Milestones=20 Dates for milestones to be decided later.=20 - Post strawman WG goals and charter.=20 - Submit WG document defining the framework and applicability of the=20 PCE model.=20 - Select a single candidate protocol from communication between LSRs=20 and PCEs.=20 - Submit document(s) that define various path computation models=20 - Submit an analysis document examining the requirements for coherent=20 computation techniques and the implication of cooperation between=20 PCEs.=20 - Submit a document defining the protocol for communication between=20 LSRs and PCEs.=20 - Submit document(s) defining extensions to routing and signalling=20 protocols necessary to support the use of a PCE model within MPLS=20 networks.=20 - Submit a document defining MIB modules for modeling and management=20 of PCE systems. ------_=_NextPart_001_01C47DEC.24650716 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi,
 
The
 
draft-mescal-pce-interas-00.txt
draft-mescal-pcp-interas-00.txt
draft-mescal-pceid-00.txt
 
drafts are work in progress. Further information = about=20 related work could be found in www.mescal.org.
 
Best regards,
 
Mohamed
-----Message d'origine-----
De :=20 owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]De la = part de=20 lidefeng
Envoy=A8=A6 : jeudi 5 août 2004 = 02:53
À :=20 Jean Philippe Vasseur; ccamp@ops.ietf.org; mpls@ietf.org; TEWG;=20 rtgwg@ietf.org
Cc : adrian@olddog.co.uk; zinin@psg.com; = Bill=20 Fenner
Objet : Re: PCE BOF - Thursday August 5, 13:00 = to=20 15:00

Hi,
 
I think it is very necessary to do = this work in=20 IETF, Service Providers in China also expressed such requirements = during the=20 technical exchanges.
 
I have delved into PCE.ppt in the = link, however,=20 I can't find the following drafts, If anyone can share with me? = Could you=20 please send me these drafts in e-mail, Thanks!
 
draft-mescal-pce-interas-00.txt
draft-mescal-pcp-interas-00.txt
draft-mescal-pceid-00.txt
 
Best Regards
Defeng Li 
----- Original Message -----
From:=20 Jean Philippe=20 Vasseur
To: ccamp@ops.ietf.org ; mpls@ietf.org ; TEWG ; rtgwg@ietf.org
Cc: adrian@olddog.co.uk ; zinin@psg.com ; Bill=20 Fenner
Sent: Sunday, August 01, 2004 = 1:07=20 PM
Subject: PCE BOF - Thursday = August 5,=20 13:00 to 15:00

Hi,

Just to let you know that the set of = slides for=20 the PCE BOF will be available next Monday morning (http://www.olddog.co.uk/60/pce.ppt)

C= heers,

JP=20 and Adrian.

Path Computation Element BOF (PCE BOF) =
60th IETF,=20 San Diego, August 2004

Routing Area Ads: Alex Zinin (zinin@psg.com),
Bill Fenner = (fenner@research.att.com)
<= BR>BOF=20 Chairs: JP Vasseur (jvasseur@cisco.com), Adrian = Farrel (adrian@olddog.co.uk)

Descr= iption:=20
In certain MPLS TE networks it may be beneficial or desirable to = have=20 path
computation performed by a distinct node (termed the Path=20 Computation
Element PCE) that is not the LSR that needs to know = the=20 path. This BOF
examines the scope of such function, what = extensions to=20 existing protocols
might required, what additional protocols may = need to=20 be developed, and
whether there is cuase and support for this = work=20 within the IETF.

Proposed WG Charter

Organizational = Overview=20
The PCE working group coordinates the work within the IETF of = defining=20 the
operation of path computation elements within the Internet. = Path=20
computation elements are responsible for computing paths through = IP=20
networks for uses such as traffic engineering so that a prime = consumer=20 of
such paths might be an MPLS-TE LSR. Areas of responsibility = will=20 include
the collection of attributes relevant to the computation = of=20 paths, the
discovery by LSRs of available path computation = elements, the=20 communication
with LSRs for the request of path computation, the = collaboration between
path computation elements within the = network, and=20 analysis of path
computation algorithms with a view to ensuring=20 consistency between computed
paths. The working group will work = closely=20 with many working groups in the
Routing Area including the OSPF, = IS-IS,=20 IDR, MPLS and CCAMP working groups.

Working Group Scope =

The=20 PCE working group scope includes:
- Definition of Generalized = Traffic=20 Engineered LSP paths computation
techniques involving Path = Computation=20 Element(s). This includes the intra
IGP area, inter IGP area, = inter-AS=20 and inter-provider TE LSPs path
computation for Point-to-Point,=20 Point-to-Multipoint and
Multipoint-to-Multipoint TE LSPs.
-=20 Definition of protocol-independent metrics and constraints defining = path=20
quality measurement criteria, algorithm complexity and = scalability=20 criteria
related to path computation techniques.
- = Definition of=20 requirements for communication between LSRs and PCEs
including = routing=20 extensions in support of PCE discovery techniques within
an IGP = area and=20 across multiple IGP areas, ASes and Provider networks, and =
including the=20 development of new protocols or protocol extensions for =
requesting path=20 computation and supplying responses. Any protocol
extensions = will=20 developed in conjunction with the working groups in charge
of = the=20 specific protocols.
- Specification of routing (OSPF, ISIS, BGP) = and=20 signalling extensions
(RSVP-TE) required by PCE-based path = computation=20 techniques. The extensions
will developed in conjunction with = the=20 working groups in charge of the
specific protocols.
- = Specification=20 of requirements and protocol extensions related to the
policy, = security=20 and confidentiality aspects of PCE-based path computation =
techniques=20 involving PCEs of multiple Providers.
- Definition of MIBs, = management=20 procedures related to the protocol
extensions defined by the WG =
In=20 doing this work, the WG will closely work with at least the = following=20
other WGs: CCAMP, MPLS, ISIS, OSPF, IDR. The WG will also = cooperate with=20
the ITU-T and OIF.

Goals and Milestones
Dates for = milestones=20 to be decided later.
- Post strawman WG goals and charter.
- = Submit=20 WG document defining the framework and applicability of the
PCE = model.=20
- Select a single candidate protocol from communication between = LSRs=20
and PCEs.
- Submit document(s) that define various path = computation=20 models
- Submit an analysis document examining the requirements = for=20 coherent
computation techniques and the implication of = cooperation=20 between
PCEs.
- Submit a document defining the protocol for=20 communication between
LSRs and PCEs.
- Submit document(s) = defining=20 extensions to routing and signalling
protocols necessary to = support the=20 use of a PCE model within MPLS
networks.
- Submit a document = defining MIB modules for modeling and management
of PCE=20 systems.
------_=_NextPart_001_01C47DEC.24650716-- --===============0994592947== 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 --===============0994592947==-- From mpls-bounces@ietf.org Mon Aug 9 17:05: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 RAA17506; Mon, 9 Aug 2004 17:05:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuHOo-0001cf-7h; Mon, 09 Aug 2004 17:09:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuH3X-0003Nl-O6; Mon, 09 Aug 2004 16:47:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuGSP-0007AN-VJ for mpls@megatron.ietf.org; Mon, 09 Aug 2004 16:09: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 QAA08197 for ; Mon, 9 Aug 2004 16:09:19 -0400 (EDT) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuGWn-00077g-Ke for mpls@ietf.org; Mon, 09 Aug 2004 16:13:54 -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 i79K6ABm072261; Mon, 9 Aug 2004 13:06:10 -0700 (PDT) (envelope-from rahul@juniper.net) Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i79K6Ae18380; Mon, 9 Aug 2004 13:06:10 -0700 (PDT) (envelope-from rahul@juniper.net) Received: from localhost (rahul@localhost) by sapphire.juniper.net (8.11.6/8.11.3) with ESMTP id i79K6At93130; Mon, 9 Aug 2004 13:06:10 -0700 (PDT) (envelope-from rahul@juniper.net) X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs Date: Mon, 9 Aug 2004 13:06:10 -0700 (PDT) From: Rahul Aggarwal To: zafar ali Subject: RE: [mpls] Re: draft-raggarwa-mpls-rsvp-te-p2mp-00.txt In-Reply-To: <002b01c47bed$f5258940$0200a8c0@amer.cisco.com> Message-ID: <20040808225455.R94750@sapphire.juniper.net> References: <002b01c47bed$f5258940$0200a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: 538aad3a3c4f01d8b6a6477ca4248793 Hi Zafar, On Fri, 6 Aug 2004, zafar ali wrote: > Hi Rahul, et al > > During the WG meeting, there were a number of major comments were made on > the requirement document. Given this, I don't think we have a case for > adapting solution document by the WG. > Can you explain which specific comments on draft-ietf-mpls-p2mp-requirement-03.txt impact the adoption of draft-raggarwa-mpls-rsvp-te-p2mp-00.txt as a MPLS WG document (i.e. for this draft being a reasonable basis for the soulutions work) ? thanks, rahul > Thanks > > Regards... Zafar > > >-----Original Message----- > >From: mpls-bounces@lists.ietf.org > >[mailto:mpls-bounces@lists.ietf.org] On Behalf Of Rahul Aggarwal > >Sent: Thursday, August 05, 2004 5:51 PM > >To: swallow@cisco.com; loa@pi.se > >Cc: mpls@ietf.org > >Subject: [mpls] Re: draft-raggarwa-mpls-rsvp-te-p2mp-00.txt > > > > > > > >Hi George and Loa, > > > >The authors of draft-raggarwa-mpls-rsvp-te-p2mp-00.txt would > >like to request it to become a WG document. > > > >Thanks, > >rahul > > > >_______________________________________________ > >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 Aug 10 11:45: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 LAA05706; Tue, 10 Aug 2004 11:45:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuYsm-0006zt-Ky; Tue, 10 Aug 2004 11:49:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuYkh-00051c-BJ; Tue, 10 Aug 2004 11:41:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuYe5-0003iX-Ov for mpls@megatron.ietf.org; Tue, 10 Aug 2004 11:34: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 LAA04791 for ; Tue, 10 Aug 2004 11:34:34 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuYia-0006lu-Ck for mpls@ietf.org; Tue, 10 Aug 2004 11:39:21 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 10 Aug 2004 11:42:33 -0400 X-BrightmailFiltered: true Received: from zaliw2k01 (rtp-vpn2-374.cisco.com [10.82.241.118]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7AFXtA6002116; Tue, 10 Aug 2004 11:33:56 -0400 (EDT) From: "zafar ali" To: "'Rahul Aggarwal'" Subject: RE: [mpls] Re: draft-raggarwa-mpls-rsvp-te-p2mp-00.txt Date: Tue, 10 Aug 2004 11:35:26 -0400 Organization: Cisco Systems Message-ID: <000001c47eef$a99c8ff0$0200a8c0@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.5709 Importance: Normal In-Reply-To: <20040808225455.R94750@sapphire.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Hi Rahul, - The requirement document had some major issues raised against it at the last WG meeting. I would suggest that we wait for the meeting minutes and debate some issues at that point. In any case, you are asking me to compare the solution document with the requirements that are in flux. - There is a dependency for this work with multicast WG. Chairs can correct me if I am wrong, but some "formal" interaction between the WGs is required (I think you agreed to this aspect in the WG meeting). Thanks Regards... Zafar >-----Original Message----- >From: mpls-bounces@lists.ietf.org >[mailto:mpls-bounces@lists.ietf.org] On Behalf Of Rahul Aggarwal >Sent: Monday, August 09, 2004 4:06 PM >To: zafar ali >Cc: mpls@ietf.org >Subject: RE: [mpls] Re: draft-raggarwa-mpls-rsvp-te-p2mp-00.txt > > > >Hi Zafar, > >On Fri, 6 Aug 2004, zafar ali wrote: > >> Hi Rahul, et al >> >> During the WG meeting, there were a number of major comments >were made >> on the requirement document. Given this, I don't think we >have a case >> for adapting solution document by the WG. >> > >Can you explain which specific comments on >draft-ietf-mpls-p2mp-requirement-03.txt >impact the adoption of draft-raggarwa-mpls-rsvp-te-p2mp-00.txt >as a MPLS WG document (i.e. for this draft being a reasonable >basis for the soulutions work) ? > >thanks, >rahul > >> Thanks >> >> Regards... Zafar >> >> >-----Original Message----- >> >From: mpls-bounces@lists.ietf.org >> >[mailto:mpls-bounces@lists.ietf.org] On Behalf Of Rahul Aggarwal >> >Sent: Thursday, August 05, 2004 5:51 PM >> >To: swallow@cisco.com; loa@pi.se >> >Cc: mpls@ietf.org >> >Subject: [mpls] Re: draft-raggarwa-mpls-rsvp-te-p2mp-00.txt >> > >> > >> > >> >Hi George and Loa, >> > >> >The authors of draft-raggarwa-mpls-rsvp-te-p2mp-00.txt >would like to >> >request it to become a WG document. >> > >> >Thanks, >> >rahul >> > >> >_______________________________________________ >> >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 Aug 12 05:35: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 FAA16068; Thu, 12 Aug 2004 05:35:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvC51-0007xZ-Kg; Thu, 12 Aug 2004 05:41:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvBus-0005t3-KY; Thu, 12 Aug 2004 05:30:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvBt3-0005dt-4y for mpls@megatron.ietf.org; Thu, 12 Aug 2004 05:28:41 -0400 Received: from ca.ibm.com ([200.167.32.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA15826; Thu, 12 Aug 2004 05:28:28 -0400 (EDT) Received: from unknown (113.153.53.83) by rsmail.alkoholic.net with asmtp; Thu, 12 Aug 2004 21:28:40 -0500 Received: from mtu23.bigping.com ([172.150.194.238]) by qrx.quickslick.com with SMTP; Thu, 12 Aug 2004 16:22:43 -0700 Message-ID: From: "Aaron" To: "Postmaster" Date: Thu, 12 Aug 2004 04:14:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [mpls] M-L-M is definitely OUT - dont even touch it! 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: 21.9 (+++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Since many Opport-unities on the Net are of dubious nature, it's getting noticeably catchier to filter out the good, legit ones! Ask for detailed Information that helps you make a firm decision in the future! Remember: Never leave out spending time doing your Due Diligence first! It will save you lots of disappointment. To receive fr-ee Help and Education about this essential topic, email to GlobalBiz@nerdshack.com with "Provide Education" in the top line. Do NOT hit the Reply button to this message. To be unlisted just email to NoMail@nerdshack.com with "NoInfo" in the top line. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Aug 17 15:01: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 PAA07637; Tue, 17 Aug 2004 15:01:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx9JW-0002AK-Vt; Tue, 17 Aug 2004 15:08:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx94l-0002dt-8Q; Tue, 17 Aug 2004 14:52:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx920-0001x2-Px for mpls@megatron.ietf.org; Tue, 17 Aug 2004 14:50:00 -0400 Received: from av7-2-sn1.fre.skanova.net (av7-2-sn1.fre.skanova.net [81.228.11.114]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06897 for ; Tue, 17 Aug 2004 14:49:58 -0400 (EDT) Received: by av7-2-sn1.fre.skanova.net (Postfix, from userid 502) id F004C37ED8; Tue, 17 Aug 2004 20:49:27 +0200 (CEST) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av7-2-sn1.fre.skanova.net (Postfix) with ESMTP id DF8B537E43 for ; Tue, 17 Aug 2004 20:49:27 +0200 (CEST) Received: from [127.0.0.1] (h60n2fls307o1033.telia.com [81.226.61.60]) by smtp3-2-sn1.fre.skanova.net (Postfix) with ESMTP id 87FE037E5F for ; Tue, 17 Aug 2004 20:49:27 +0200 (CEST) Message-ID: <41225336.7030901@pi.se> Date: Tue, 17 Aug 2004 20:49:26 +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=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA06897 Subject: [mpls] MPLS2004 Program 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: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: quoted-printable MPLS 2004 International Conference Omni Shoreham Hotel, Washington DC October 17-19, 2004 http://www.mpls2004.com You are cordially invited to attend the MPLS 2004 International Conference to be held in Washington DC. October 17-19, 2004 hosted by=20 ISOCORE. The 3-day event consists of highly technical sessions, tutorials, panel discussions, and exhibits. Registration for the conference is now open. Early registration discounts are highly attractive and are valid for a limited time only. To register, go to: http://www.mpls2004.com/registration.htm Important Dates: --------------------- - Early Registration Rates Cut-Off Date: August 31 - Tutorials: October 17, 8:30 am - 6:30 pm - Technical Tracks: October 18-19, 8:30 am - 6:30 pm - Exhibits: October 18, 9:00 am - 6:00 pm October 19, 9:00 am - 3:00 pm Program: -------- (visit http://www.isocore.com/mpls2004/program.htm#oct1819 for details) Sunday, October 17 Tutorials and Exhibit Set up Monday, October 18 AM-1: 8:30-10:00 am Introduction: Dr. B. Jabbari Remarks: Conference Co-Chair, Dr. S. Elby, VP, Network Architecture and Enterprise Technologies, Verizon Technology Organization Remarks: Conference Co-Chair, T. Matsunaga Head and Executive Manager, NT= T Network Service Systems Labs. Keynote Speech: NTT's Vision for the Future Network, T. Okada, Vice President, Executive Director, NTT Network Service Systems Laboratories IETF Routing and MPLS Standards Update, A. Zinin, Routing Area Director,=20 IETF AM-2: 10:30 - 11:30 am Operational Experience and Architectures -Current MPLS Deployment Experience, T. McKinney, Cisco Systems -Real-time Services over an IP/MPLS Network, B. Goode, ATT -Issues in Broadband Networking Architecture, L. Andersson, Acreo AM-3: 11:30 - 12:30 am Case studies for MPLS Services -VPLS: A Case Study, M. McNamara, Time Warner Telecom -Implementing QoS in a Nation-wide Service Provider MPLS Core Network:=20 A Case Study, L. Wang, Telenor Networks -BGP/MPLS VPN Deployment Experience and Challenges, L. Fang, ATT Lunch PM-1: 2:00 - 3:30 pm Recovery and Restoration in MPLS -MPLS Fast Reroute Techniques, G. Swallow, Cisco Systems -MPLS Fast Reroute, K. Kompella, Juniper Networks -Reliable Alternate Paths for IP Destinations (RAPID), Alia Atlas, Avic= i Systems -Quantitative Comparison of MPLS Resiliency Approaches, R. Nagarajan,=20 Lucent Technologies Break PM-2: 4:00 - 5:00 pm GMPLS and IP Optical Integration -Prototyping the GMPLS UNI Implementation for End-to-End LSP=20 Re-routing, D. Verch=E8re and D.Papadimitriou, Alcatel -ASON and GMPLS: Two Ways to Do the Same Thing -- But Are They Really Different? J. Sadler, Tellabs -Emerging ITU Framework for Management of ASON/GMPLS, L. Ong, Ciena PM-3: 5:00 - 6:30 pm Panel: Inter-Carrier MPLS Issues Chair: S. Elby, VP, Network Architecture and Enterprise Technologies,=20 Verizon Technology Organization -Panelists from ISP/Carriers Tuesday AM-4: 8:30 - 10:00 am Invited talks J. Agogbua, Movaz Networks Y. Rekhter, Juniper Networks MPLS/GMPLS in Multi-Region networks -A Distributed PCE-based Solution to Compute Inter-domain Shortest TE L= SP Paths, JP Vasseur, Cisco Systems -GMPLS-based Traffic Engineering in Multi-Region/Multi-Layer Service=20 Network, K. Shiomoto, NTT Break AM-5: 10:30 - 11:30 am Operational, Administrative and Maintenance -BFD and MPLS: Marriage Made in Heaven, Z. Ali, Cisco Systems -Interworking OAM, D. Allan, Nortel Networks -MPLS OAM: Standards & Solutions, T. Nadeau, Cisco Systems -Are My LSPs Up? Are They Up Now? I. Minei, Juniper Networks AM-6: 11:30 - 12:30 pm VPNs and Advanced Services -MPLS Layer 3 and Layer 2 VPNs Over an IP Only Core, R. Aggarwal, Juni= per Networks -Deployment Scenarios for Secure Inter-AS VPNS, S. Poretsky, Quarry Technologies -VoIP and Voice Services over MPLS, J. McEachern, Nortel Networks Lunch PM-4: 2:00 - 3:30 pm Point to Multi-Point and Multicast Services -P2MP TE LSPs (MPLS and GMPLS), D. Papadimitriou, Alcatel -Multicast Issues, M. Finlayson, Data Connection Operational Aspects of MPLS -IGP and BGP Convergence Impacts on MPLS Convergence, S. Hares, NextHop Technologies -Fast Reroute for IP and LDP-based Networks, A. Tian, Redback Networks Break PM-5: 4:00 - 5:00 pm Experience from GMPLS Networks -Layer 1 Virtual Private Networks, T. Takeda, NTT -Demonstration of MPLS and IPv6 transport over GMPLS-controlled Optical Networks, T. Otani, KDDI R&D Labs -Acreo National Testbed, Experiences and Results, T. Madsen, Acreo -escience Experimental GMPLS Network, J. Sobieski, MAX PM-6: 5:00 - 6:30 pm Panel Session: Vendor's Perspective on MPLS Chair: Dr. D. Awduche (MCI) A. Sayeed (Cisco Systems), A. Malis (Tellabs), J. Sax (Lucent Technologie= s), Craig Easely (Extreme Networks), D. Fedyk (Nortel Networks), S. Khandekar (Alcatel). _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Aug 18 16:54: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 QAA15652; Wed, 18 Aug 2004 16:54:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxXYX-0001BA-D0; Wed, 18 Aug 2004 17:01:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxXGB-0002cF-8P; Wed, 18 Aug 2004 16:42:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxW5U-0004hK-Tg; Wed, 18 Aug 2004 15:27:08 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01559; Wed, 18 Aug 2004 15:26:37 -0400 (EDT) Message-Id: <200408181926.PAA01559@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, 18 Aug 2004 15:26:37 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-lc-if-mib-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: 8de5f93cb2b4e3bee75302e9eacc33db --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-03.txt Pages : 19 Date : 2004-8-18 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-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-lc-if-mib-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-lc-if-mib-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-8-18143149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lc-if-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lc-if-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-18143149.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 Aug 19 20: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 UAA22432; Thu, 19 Aug 2004 20:42:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxxaR-0002qX-5e; Thu, 19 Aug 2004 20:48:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxxPp-0002v4-Eb; Thu, 19 Aug 2004 20:37:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxxMt-00022A-5L for mpls@megatron.ietf.org; Thu, 19 Aug 2004 20:34: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 UAA22054 for ; Thu, 19 Aug 2004 20:34:54 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxxTP-0002i5-4w for mpls@ietf.org; Thu, 19 Aug 2004 20:41:40 -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 i7K0YJ983648; Thu, 19 Aug 2004 17:34:19 -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 i7K0YEe16861; Thu, 19 Aug 2004 17:34:14 -0700 (PDT) (envelope-from ina@juniper.net) Date: Thu, 19 Aug 2004 17:34:14 -0700 (PDT) From: Ina Minei To: mpls@ietf.org Message-ID: <20040819172140.A7956@garnet.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [mpls] Requesting your feedback - issues/errors/clarifications for 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: 798b2e660f1819ae38035ac1d8d5e3ab RFC3036 (LDP specification) is advancing to draft standard. As part of this process, it is necessary to compile a list of changes/clarifications to the rfc, based on the experience gained with the protocol. Please send me errors/changes/clarifications that you know about, so that they can be taken into account in the revised document. Please send your comments by September 6, either directly to me or to the list. I will post the complete list of the issues a couple of weeks later. Thank you, Ina _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Aug 19 22:39: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 WAA27215; Thu, 19 Aug 2004 22:39:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxzPZ-0004nw-Eq; Thu, 19 Aug 2004 22:45:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxzEb-0007G0-6A; Thu, 19 Aug 2004 22:34:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxzCg-0006wg-BT for mpls@megatron.ietf.org; Thu, 19 Aug 2004 22:32: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 WAA26907 for ; Thu, 19 Aug 2004 22:32:28 -0400 (EDT) Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxzJA-0004gq-DQ for mpls@ietf.org; Thu, 19 Aug 2004 22:39:16 -0400 Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126) by kremlin.juniper.net with ESMTP; 19 Aug 2004 19:31:55 -0700 X-BrightmailFiltered: true X-Ironport-AV: i="3.83,98,1089010800"; d="scan'208"; a="3364578:sNHT19201520" Received: from photon.jnpr.net ([172.24.18.198]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Aug 2004 19:31:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Aug 2004 19:31:53 -0700 Message-ID: <062B922B6EC55149B5A267ECE78E5D4420D005@photon.jnpr.net> Thread-Topic: Status Thread-Index: AcSGXdrN7Hx8vaTvQjmaZLEfgACFQAAAABM8 From: "Arunachalam Selvarajan" To: X-OriginalArrivalTime: 20 Aug 2004 02:31:54.0575 (UTC) FILETIME=[DB7DC5F0:01C4865D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Content-Transfer-Encoding: quoted-printable Subject: [mpls] Out of Office AutoReply: Status 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: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: quoted-printable I will be on vacation till Sep.18th and please contact my manager Partha Sarathy for any emergency _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Aug 24 17:05: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 RAA11429; Tue, 24 Aug 2004 17:05:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BziUW-0000s9-O6; Tue, 24 Aug 2004 17:06:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzi3v-0004FZ-Oz; Tue, 24 Aug 2004 16:38:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzhkD-0006u0-QL for mpls@megatron.ietf.org; Tue, 24 Aug 2004 16:18: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 QAA08740 for ; Tue, 24 Aug 2004 16:18:06 -0400 (EDT) Received: from [208.246.215.5] (helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzhki-0008U3-5Y for mpls@ietf.org; Tue, 24 Aug 2004 16:18:45 -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 i7OKHDZ1019139; Tue, 24 Aug 2004 16:17:18 -0400 Message-Id: <200408242017.i7OKHDZ1019139@mailhost.avici.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Markus Jork To: Ina Minei In-reply-to: Your message of "Thu, 19 Aug 2004 17:34:14 PDT." <20040819172140.A7956@garnet.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Aug 2004 16:17:13 -0400 X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean Subject: Re: [mpls] Requesting your feedback - issues/errors/clarifications 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 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 > > RFC3036 (LDP specification) is advancing to draft standard. > > As part of this process, it is necessary to compile a list of > changes/clarifications to the rfc, based on the experience gained with the > protocol. > > Please send me errors/changes/clarifications that you know about, > so that they can be taken into account in the revised document. Please > send your comments by September 6, either directly to me or to the list. Here is one issue: The spec defines two types of FECs: "address prefix" and "host address". The address prefix FEC is what's in widespread use. We have also implemented support for the host address FEC but I have never seen it used. It would be interesting to know whether there is any known actual use of it. If not, I suggest to remove it from the spec. Markus > I will post the complete list of the issues a couple of weeks > later. > > Thank you, > > Ina _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Aug 24 19:07: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 TAA21299; Tue, 24 Aug 2004 19:07:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzkP3-00035M-WB; Tue, 24 Aug 2004 19:08:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzjt5-0001QS-Vv; Tue, 24 Aug 2004 18:35:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzjhQ-0005Qe-TE for mpls@megatron.ietf.org; Tue, 24 Aug 2004 18:23:33 -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 SAA18762 for ; Tue, 24 Aug 2004 18:23:20 -0400 (EDT) Received: from [64.47.51.130] (helo=exchange.timetra.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzjhx-0002Kw-6X for mpls@ietf.org; Tue, 24 Aug 2004 18:24:01 -0400 Received: from vkompellaxp ([192.168.5.178] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 24 Aug 2004 15:22:36 -0700 From: "Vach Kompella" To: "'Markus Jork'" , "'Ina Minei'" Subject: RE: [mpls] Requesting your feedback - issues/errors/clarifications Date: Tue, 24 Aug 2004 15:24:44 -0700 Organization: Alcatel USA Message-ID: <08f501c48a29$2b57e7d0$0101010a@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 In-Reply-To: <200408242017.i7OKHDZ1019139@mailhost.avici.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-OriginalArrivalTime: 24 Aug 2004 22:22:36.0861 (UTC) FILETIME=[DC107ED0:01C48A28] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org 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: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable I agree we should get rid of the host FEC type. Issue: it would be nice to be able to shut down an adjacency without having to time it out. E.g., two interfaces between the same pair of nodes running LDP. If one is shut down, there is no way to notify the peer endpoint, e.g., notification message to the multicast address over UDP. Issue: do we really have to send all FECs in our database whenever we have an LDP session between two peers? E.g., A is a PE which does LDP for address FECs as well as PW FECs. If it sets up a targeted adjacency clear across the network to another PE, does it really have to send all its address FECs there? In our implementation, we do not send address FECs across a session that was set up with a targeted adjacency, since we only use targeted adjacencies for PW FECs. Issue: with all the combinations of Downstream Unsolicited, Downstream on Demand, Ordered Control, Independent Control, etc., it makes sense to define a mandatory combination. DU/OC seems to be the favored one. E.g., IC was useful back when MPLS LSPs replaced IP forwarding. Now that that isn't the case anymore, if there is a P router doing independent control in the middle of the network, it propagates a FEC for a tunnel that may be used by 2547, BGP-free core routing, or PWs, falsely giving the impression that the PSN tunnel is end to end. It would be far better to identify, at ingress, that the tunnel is not up. In either case, we blackhole packets, but in one case, we clearly know the service is not up, the route is not resolvable, etc., while in the other, you have to figure that there is a problem somewhere in the middle of the network. Issue: Minor optimization: why do you send a FEC back to the owner of the FEC? E.g., A sends its loopback to B. Why should B send it right back to A (as described in LMp.21)? 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? -Vach=20 > -----Original Message----- > From: mpls-bounces@lists.ietf.org=20 > [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Markus Jork > Sent: Tuesday, August 24, 2004 1:17 PM > To: Ina Minei > Cc: mpls@ietf.org > Subject: Re: [mpls] Requesting your feedback -=20 > issues/errors/clarifications >=20 >=20 > >=20 > > RFC3036 (LDP specification) is advancing to draft standard. > >=20 > > As part of this process, it is necessary to compile a list of=20 > > changes/clarifications to the rfc, based on the experience=20 > gained with=20 > > the protocol. > >=20 > > Please send me errors/changes/clarifications that you=20 > know about, so=20 > > that they can be taken into account in the revised document. Please=20 > > send your comments by September 6, either directly to me or to the=20 > > list. >=20 > Here is one issue: > The spec defines two types of FECs: "address prefix" and=20 > "host address". The address prefix FEC is what's in=20 > widespread use. We have also implemented support for the host=20 > address FEC but I have never seen it used. It would be=20 > interesting to know whether there is any known actual use of=20 > it. If not, I suggest to remove it from the spec. >=20 > Markus >=20 >=20 > > I will post the complete list of the issues a couple of=20 > weeks later. > >=20 > > Thank you, > >=20 > > Ina >=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 Tue Aug 24 19:09: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 TAA21528; Tue, 24 Aug 2004 19:09:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzkR3-00037N-Up; Tue, 24 Aug 2004 19:10:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzjsA-0001AB-Ci; Tue, 24 Aug 2004 18:34:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzjZh-0002NO-Gz for mpls@megatron.ietf.org; Tue, 24 Aug 2004 18:15: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 SAA17774 for ; Tue, 24 Aug 2004 18:15:21 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzja3-0002Bh-QQ for mpls@ietf.org; Tue, 24 Aug 2004 18:16:02 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 25 Aug 2004 00:26:06 +0200 X-BrightmailFiltered: true Received: from [209.245.27.1] ([10.32.224.186]) by ams-core-1.cisco.com (8.12.10/8.12.6) with SMTP id i7OMEbuS013773; Wed, 25 Aug 2004 00:14:38 +0200 (MEST) Message-ID: <412BBDC8.1010603@cisco.com> Date: Tue, 24 Aug 2004 16:14:32 -0600 From: Luca Martini Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040620 X-Accept-Language: en-us, en, fr, it MIME-Version: 1.0 To: Ina Minei Subject: Re: [mpls] Requesting your feedback - issues/errors/clarifications for RFC3036 References: <20040819172140.A7956@garnet.juniper.net> In-Reply-To: <20040819172140.A7956@garnet.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.99824 X-from-outside-Cisco: [10.32.224.186] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Ina, The following text needs more explanation: RFC3036: F bit Forward unknown TLV bit. This bit applies only when the U bit is set and the LDP message containing the unknown TLV is to be forwarded. If F is clear (=0), the unknown TLV is not forwarded with the containing message; if F is set (=1), the unknown TLV is forwarded with the containing message. The sections following that define TLVs specify a value for the F-bit. ----------------------------- If the U Bit and the F bit are set , then the extra TLV can be forwarded. I believe that somewhere we need to explain that this was intended to allow attachment of attributes to a FEC. I believe that this is used by the LDP MTU draft already, but we need some text to specify the F-bit better. Luca Luca Ina Minei wrote: > RFC3036 (LDP specification) is advancing to draft standard. > > As part of this process, it is necessary to compile a list of >changes/clarifications to the rfc, based on the experience gained with the >protocol. > > Please send me errors/changes/clarifications that you know about, >so that they can be taken into account in the revised document. Please >send your comments by September 6, either directly to me or to the list. > > I will post the complete list of the issues a couple of weeks >later. > > Thank you, > > Ina > >_______________________________________________ >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 Aug 24 19:24: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 TAA22556; Tue, 24 Aug 2004 19:24:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzkel-0003L7-3u; Tue, 24 Aug 2004 19:24:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzkJr-0001A3-Un; Tue, 24 Aug 2004 19:03:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzjtS-0001T6-Sr for mpls@megatron.ietf.org; Tue, 24 Aug 2004 18:35: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 SAA19676 for ; Tue, 24 Aug 2004 18:35:46 -0400 (EDT) Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzjty-0002Yo-IM for mpls@ietf.org; Tue, 24 Aug 2004 18:36:27 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.45]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N87XV6V0; Tue, 24 Aug 2004 18:35:16 -0400 Message-Id: <6.1.2.0.2.20040824180628.02f98438@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 24 Aug 2004 18:30:09 -0400 To: Ina Minei , mpls@ietf.org From: Mark Duffy Subject: Re: [mpls] Requesting your feedback - issues/errors/clarifications for RFC3036 In-Reply-To: <20040819172140.A7956@garnet.juniper.net> References: <20040819172140.A7956@garnet.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: a7d6aff76b15f3f56fcb94490e1052e4 > RFC3036 (LDP specification) is advancing to draft standard. > > As part of this process, it is necessary to compile a list of >changes/clarifications to the rfc, based on the experience gained with the >protocol. > > Please send me errors/changes/clarifications that you know about, >so that they can be taken into account in the revised document. Please >send your comments by September 6, either directly to me or to the list. Hi Ina, I have 2 items: 1. It would be nice to fold the content of draft-ietf-mpls-ldp-mtu-extensions-02.txt into the main LDP standard document. 2. Re LDP discovery (RFC 3036 section 2.4): Two types of peer discovery are described: Basic and Extended. Basic as described will work on broadcast and point-point media but not in general on NBMA media (e.g. non-LC-ATM when used in a multipoint mode). Extended can work on NBMA but its semantics are quite different than Basic: it allows "discovery" of peers that are more than 1 hop away, and it does not bind the Hello adjacency to a particular interface. Both of these differences can be undesirable in a context where one is looking to use LDP to distribute outer labels with adjacent peers on a non-LC NBMA network. Extended discovery appears to be primarily intended for distributing "inner" labels with non-adjacent peers. I think the successor to 3036 should either point out that basic discovery on NBMA is not provided for, or it should specify a mechanism semantically similar to basic discovery (1 hop limit, bind the hello adjacency to an interface) except using preconfigured neighbor addresses. Thanks, Mark _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Aug 24 19:33: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 TAA23510; Tue, 24 Aug 2004 19:33:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzknc-0003W5-3H; Tue, 24 Aug 2004 19:33:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzkJy-0001Ja-TJ; Tue, 24 Aug 2004 19:03:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzk0b-0003SU-Ml for mpls@megatron.ietf.org; Tue, 24 Aug 2004 18:43: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 SAA20048 for ; Tue, 24 Aug 2004 18:43:09 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzk17-0002fy-Cc for mpls@ietf.org; Tue, 24 Aug 2004 18:43:50 -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 i7OMge922075; Tue, 24 Aug 2004 15:42:40 -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 i7OMgZe15020; Tue, 24 Aug 2004 15:42:35 -0700 (PDT) (envelope-from ina@juniper.net) Date: Tue, 24 Aug 2004 15:42:35 -0700 (PDT) From: Ina Minei To: Mark Duffy Subject: Re: [mpls] Requesting your feedback - issues/errors/clarifications for RFC3036 In-Reply-To: <6.1.2.0.2.20040824180628.02f98438@email.quarrytech.com> Message-ID: <20040824153807.Y15770@garnet.juniper.net> References: <20040819172140.A7956@garnet.juniper.net> <6.1.2.0.2.20040824180628.02f98438@email.quarrytech.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: a7d6aff76b15f3f56fcb94490e1052e4 Mark, Thank you for your feedback, please see inline below. > > 1. It would be nice to fold the content of > draft-ietf-mpls-ldp-mtu-extensions-02.txt into the main LDP standard document. From a standards point of view, this cannot be done, since the mtu extensions is not yet an RFC. Regarding the second point, I will send all comments together to the list for review/discussion after receiving all the feedback. Ina > > 2. Re LDP discovery (RFC 3036 section 2.4): Two types of peer discovery > are described: Basic and Extended. Basic as described will work on > broadcast and point-point media but not in general on NBMA media (e.g. > non-LC-ATM when used in a multipoint mode). > > Extended can work on NBMA but its semantics are quite different than Basic: > it allows "discovery" of peers that are more than 1 hop away, and it does > not bind the Hello adjacency to a particular interface. Both of these > differences can be undesirable in a context where one is looking to use LDP > to distribute outer labels with adjacent peers on a non-LC NBMA > network. Extended discovery appears to be primarily intended for > distributing "inner" labels with non-adjacent peers. > > I think the successor to 3036 should either point out that basic discovery > on NBMA is not provided for, or it should specify a mechanism semantically > similar to basic discovery (1 hop limit, bind the hello adjacency to an > interface) except using preconfigured neighbor addresses. > > Thanks, Mark > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Aug 24 22:27: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 WAA05238; Tue, 24 Aug 2004 22:27:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BznWI-0006x7-4d; Tue, 24 Aug 2004 22:28:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzmtS-0000ka-3G; Tue, 24 Aug 2004 21:48:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzmWu-0005Px-Ta for mpls@megatron.ietf.org; Tue, 24 Aug 2004 21:24: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 VAA00805 for ; Tue, 24 Aug 2004 21:24:41 -0400 (EDT) Received: from [208.246.215.5] (helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzmXT-0005eP-1I for mpls@ietf.org; Tue, 24 Aug 2004 21:25:23 -0400 Received: from LAVANYAKISHORE ([10.2.103.41]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id i7P1O3Z2019030; Tue, 24 Aug 2004 21:24:06 -0400 From: "Kishore Tiruveedhula" To: "Ina Minei" , "Mark Duffy" Subject: RE: [mpls] Requesting your feedback - issues/errors/clarificationsfor RFC3036 Date: Tue, 24 Aug 2004 21:23:34 -0400 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20040824153807.Y15770@garnet.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal 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: 31247fb3be228bb596db9127becad0bc 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: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Here is one more issue: In case of loopdetection enabled in Downstream Unsolicited mode, need to address the following issue. Router A Router B -------- -------- Send Label Mapping Recv Label Mapping Send Label Release (due to Loop found). NHOP Changes Send Label Mapping (with new pv tlvs) Recv Label Release Recv Label Mapping. In the above scenario, "A" ends up with no label advertised to "B", But "B" has received label from "A". Probably, the Label Release message should carry the message id (mandatory) to indicate exactly this is an ack for which message. Thanks, Kishore -----Original Message----- From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org]On Behalf Of Ina Minei Sent: Tuesday, August 24, 2004 6:43 PM To: Mark Duffy Cc: mpls@ietf.org Subject: Re: [mpls] Requesting your feedback - issues/errors/clarificationsfor RFC3036 Mark, Thank you for your feedback, please see inline below. > > 1. It would be nice to fold the content of > draft-ietf-mpls-ldp-mtu-extensions-02.txt into the main LDP standard document. From a standards point of view, this cannot be done, since the mtu extensions is not yet an RFC. Regarding the second point, I will send all comments together to the list for review/discussion after receiving all the feedback. Ina > > 2. Re LDP discovery (RFC 3036 section 2.4): Two types of peer discovery > are described: Basic and Extended. Basic as described will work on > broadcast and point-point media but not in general on NBMA media (e.g. > non-LC-ATM when used in a multipoint mode). > > Extended can work on NBMA but its semantics are quite different than Basic: > it allows "discovery" of peers that are more than 1 hop away, and it does > not bind the Hello adjacency to a particular interface. Both of these > differences can be undesirable in a context where one is looking to use LDP > to distribute outer labels with adjacent peers on a non-LC NBMA > network. Extended discovery appears to be primarily intended for > distributing "inner" labels with non-adjacent peers. > > I think the successor to 3036 should either point out that basic discovery > on NBMA is not provided for, or it should specify a mechanism semantically > similar to basic discovery (1 hop limit, bind the hello adjacency to an > interface) except using preconfigured neighbor addresses. > > Thanks, Mark > _______________________________________________ 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 Aug 25 06:37: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 GAA02181; Wed, 25 Aug 2004 06:37:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzvA2-00078U-Q4; Wed, 25 Aug 2004 06:38:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzuXX-00009I-9e; Wed, 25 Aug 2004 05:57:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzuPx-0006aE-DZ for mpls@megatron.ietf.org; Wed, 25 Aug 2004 05:50:09 -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 FAA29407 for ; Wed, 25 Aug 2004 05:50:02 -0400 (EDT) Received: from [12.129.211.119] (helo=host19.ipowerweb.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzuQZ-0006Gp-5E for mpls@ietf.org; Wed, 25 Aug 2004 05:50:48 -0400 Received: from h00a0ccd1a9ec.ne.client2.attbi.com ([24.61.197.198] helo=GraIyMage.com) by host19.ipowerweb.com with asmtp (Exim 3.36 #1) id 1BzuLp-0005k2-00; Wed, 25 Aug 2004 02:45:53 -0700 Message-ID: <412C5FCB.3040701@GraIyMage.com> Date: Wed, 25 Aug 2004 05:45:47 -0400 From: Eric Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ina Minei Subject: Re: [mpls] Requesting your feedback - issues/errors/clarifications for RFC3036 References: <20040819172140.A7956@garnet.juniper.net> <6.1.2.0.2.20040824180628.02f98438@email.quarrytech.com> <20040824153807.Y15770@garnet.juniper.net> In-Reply-To: <20040824153807.Y15770@garnet.juniper.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: 82c9bddb247d9ba4471160a9a865a5f3 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: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Ina, From an IETF standards process perspective, what you say below is not strictly correct. That does not mean that your conclusion is incorrect. :-) You cannot refer to the MTU extensions work in progress as a normative reference until it is an RFC. However, if it turns out that LDP implementations typically include these extensions and multiple such implementations are found to not only include it but interoperate as well, then you certainly _could_ "fold in" the actual contents (at least as actually implemented). In fact, if a number of implementation reports indicated that implementing these extensions was needed in order to achieve interoperability, you would have to do so. Assuming these extensions are not required to make LDP work (I believe this to be the case) then the fact that you _could_ "fold in" the extensions does not mean that you should. In fact, from the perspective that "options are (often) bad", you should not. So, while I agree with the conclusion that we don't want to do this, I have to object to the (possibly precedent setting) statement that "this cannot be done". -- Eric Ina Minei wrote: > Mark, > > Thank you for your feedback, please see inline below. > > > >>1. It would be nice to fold the content of >>draft-ietf-mpls-ldp-mtu-extensions-02.txt into the main LDP standard document. >> >> > > From a standards point of view, this cannot be done, since the mtu >extensions is not yet an RFC. > > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Aug 25 09:42: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 JAA14549; Wed, 25 Aug 2004 09:42:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzy39-00024y-Dn; Wed, 25 Aug 2004 09:42:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzxYR-000208-EY; Wed, 25 Aug 2004 09:11:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzxB0-0006Qu-HG for mpls@megatron.ietf.org; Wed, 25 Aug 2004 08: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 IAA11182 for ; Wed, 25 Aug 2004 08:46:48 -0400 (EDT) Received: from natint2.juniper.net ([207.17.136.150] helo=kummer.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzxBa-00014Z-Qn for mpls@ietf.org; Wed, 25 Aug 2004 08:47:35 -0400 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id i7PCk90g077176; Wed, 25 Aug 2004 05:46:09 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id i7PCk8hw077173; Wed, 25 Aug 2004 05:46:08 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 25 Aug 2004 05:46:08 -0700 (PDT) From: Kireeti Kompella To: Eric Gray Subject: Re: [mpls] Requesting your feedback - issues/errors/clarifications for RFC3036 In-Reply-To: <412C5FCB.3040701@GraIyMage.com> Message-ID: <20040825052040.C77121@kummer.juniper.net> References: <20040819172140.A7956@garnet.juniper.net> <6.1.2.0.2.20040824180628.02f98438@email.quarrytech.com> <20040824153807.Y15770@garnet.juniper.net> <412C5FCB.3040701@GraIyMage.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb On Wed, 25 Aug 2004, Eric Gray wrote: > From an IETF standards process perspective, what you say below is not > strictly correct. That does not mean that your conclusion is incorrect. :-) Ina wrote: > From a standards point of view, this cannot be done, since > the mtu extensions is not yet an RFC. You're both missing a key point. That does not mean your conclusion is incorrect :-) RFC 2026 says: 4.1.2 Draft Standard A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. While I think that the LDP MTU stuff is wonderful, folding it into a DRAFT STANDARD is soooo tomorrow -- no implementation, let alone two interoperable implementations (it is currently targeted as Experimental just for this reason), no vast storehouse of deployment experience, none of what it takes to take a doc to Draft status. Let it mature for a few years, then we can re-evaluate. The same principle should apply to anything else that people suggest get put into the DS version of 3036, *even parts of 3036* that haven't had enough exposure, implementation or deployment. Kireeti. ------- _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Aug 25 11:39:45 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 LAA24667; Wed, 25 Aug 2004 11:39:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzzt3-0004Kr-6f; Wed, 25 Aug 2004 11:40:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzzWY-0000zO-Is; Wed, 25 Aug 2004 11:17:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzzGs-0007Rj-Gi for mpls@megatron.ietf.org; Wed, 25 Aug 2004 11:01:06 -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 LAA21554 for ; Wed, 25 Aug 2004 11:00:59 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzzHU-0003Xk-KH for mpls@ietf.org; Wed, 25 Aug 2004 11:01:47 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 25 Aug 2004 11:00:28 -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 i7PF0HjF028378; Wed, 25 Aug 2004 11:00:17 -0400 (EDT) Message-Id: <200408251500.i7PF0HjF028378@rtp-core-1.cisco.com> To: vach.kompella@alcatel.com Subject: Re: [mpls] Requesting your feedback - issues/errors/clarifications In-reply-to: Your message of Tue, 24 Aug 2004 15:24:44 -0700. <08f501c48a29$2b57e7d0$0101010a@eng.timetra.com> 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: Wed, 25 Aug 2004 11:00:17 -0400 From: Eric Rosen X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: 7655788c23eb79e336f5f8ba8bce7906 > I agree we should get rid of the host FEC type. I also agree that we should get rid of the host FEC type. > Issue: do we really have to send all FECs in our database whenever we > have an LDP session between two peers? This should not be a requirement of the protocol spec, the application which is using the protocol should determine which FECS get sent. > Issue: with all the combinations of Downstream Unsolicited, Downstream > on Demand, Ordered Control, Independent Control, etc., it makes sense to > define a mandatory combination. DU/OC seems to be the favored one. I believe this would put a majority of the deployed LDP speakers out of spec. Such a change cannot be made as part of going to DS. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Aug 25 12:25: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 MAA28334; Wed, 25 Aug 2004 12:25:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C00bE-0005AN-CY; Wed, 25 Aug 2004 12:26:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C005U-0006BI-Rw; Wed, 25 Aug 2004 11:53:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzznO-0003gr-Tw for mpls@megatron.ietf.org; Wed, 25 Aug 2004 11:34:43 -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 LAA24158 for ; Wed, 25 Aug 2004 11:34:35 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzzo4-0004Cp-Dc for mpls@ietf.org; Wed, 25 Aug 2004 11:35:24 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 25 Aug 2004 17:45:43 +0200 X-BrightmailFiltered: true Received: from [209.245.27.1] ([10.32.224.186]) by ams-core-1.cisco.com (8.12.10/8.12.6) with SMTP id i7PFXvuS009023; Wed, 25 Aug 2004 17:33:58 +0200 (MEST) Message-ID: <412CB15F.8080300@cisco.com> Date: Wed, 25 Aug 2004 09:33:51 -0600 From: Luca Martini Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040620 X-Accept-Language: en-us, en, fr, it MIME-Version: 1.0 To: vach.kompella@alcatel.com Subject: Re: [mpls] Requesting your feedback - issues/errors/clarifications References: <08f501c48a29$2b57e7d0$0101010a@eng.timetra.com> In-Reply-To: <08f501c48a29$2b57e7d0$0101010a@eng.timetra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.99824 X-from-outside-Cisco: [10.32.224.186] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit Vach Kompella wrote: >I agree we should get rid of the host FEC type. > >Issue: it would be nice to be able to shut down an adjacency without >having to time it out. E.g., two interfaces between the same pair of >nodes running LDP. If one is shut down, there is no way to notify the >peer endpoint, e.g., notification message to the multicast address over >UDP. > >Issue: do we really have to send all FECs in our database whenever we >have an LDP session between two peers? E.g., A is a PE which does LDP >for address FECs as well as PW FECs. If it sets up a targeted adjacency >clear across the network to another PE, does it really have to send all >its address FECs there? In our implementation, we do not send address >FECs across a session that was set up with a targeted adjacency, since >we only use targeted adjacencies for PW FECs. > >Issue: with all the combinations of Downstream Unsolicited, Downstream >on Demand, Ordered Control, Independent Control, etc., it makes sense to >define a mandatory combination. DU/OC seems to be the favored one. >E.g., IC was useful back when MPLS LSPs replaced IP forwarding. Now >that that isn't the case anymore, if there is a P router doing >independent control in the middle of the network, it propagates a FEC >for a tunnel that may be used by 2547, BGP-free core routing, or PWs, >falsely giving the impression that the PSN tunnel is end to end. It >would be far better to identify, at ingress, that the tunnel is not up. >In either case, we blackhole packets, but in one case, we clearly know >the service is not up, the route is not resolvable, etc., while in the >other, you have to figure that there is a problem somewhere in the >middle of the network. > > > Actually I disagree. If anyting we should have DU/IC , the ordered control caused lot's of operational problems , and it took almost a year to get it working properly. There are a number of situations that cause problems in ordered control mode , but not in independent control. Most of these issues are due to timing. >Issue: Minor optimization: why do you send a FEC back to the owner of >the FEC? E.g., A sends its loopback to B. Why should B send it right >back to A (as described in LMp.21)? > >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? > > > No sure I understand what you mean here. LDP cannot know what path is selected, so it must send all the FECs. Luca >-Vach > > > >>-----Original Message----- >>From: mpls-bounces@lists.ietf.org >>[mailto:mpls-bounces@lists.ietf.org] On Behalf Of Markus Jork >>Sent: Tuesday, August 24, 2004 1:17 PM >>To: Ina Minei >>Cc: mpls@ietf.org >>Subject: Re: [mpls] Requesting your feedback - >>issues/errors/clarifications >> >> >> >> >>> RFC3036 (LDP specification) is advancing to draft standard. >>> >>> As part of this process, it is necessary to compile a list of >>>changes/clarifications to the rfc, based on the experience >>> >>> >>gained with >> >> >>>the protocol. >>> >>> Please send me errors/changes/clarifications that you >>> >>> >>know about, so >> >> >>>that they can be taken into account in the revised document. Please >>>send your comments by September 6, either directly to me or to the >>>list. >>> >>> >>Here is one issue: >>The spec defines two types of FECs: "address prefix" and >>"host address". The address prefix FEC is what's in >>widespread use. We have also implemented support for the host >>address FEC but I have never seen it used. It would be >>interesting to know whether there is any known actual use of >>it. If not, I suggest to remove it from the spec. >> >>Markus >> >> >> >> >>> I will post the complete list of the issues a couple of >>> >>> >>weeks later. >> >> >>> Thank you, >>> >>> Ina >>> >>> >> >>_______________________________________________ >>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 Wed Aug 25 14:35: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 OAA07874; Wed, 25 Aug 2004 14:35:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C02cl-0007Y3-IJ; Wed, 25 Aug 2004 14:35:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0295-00013A-K6; Wed, 25 Aug 2004 14:05:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C01pD-0006rc-0e for mpls@megatron.ietf.org; Wed, 25 Aug 2004 13:44:43 -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 NAA04335 for ; Wed, 25 Aug 2004 13:44: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 1C01py-0006gC-0X for mpls@ietf.org; Wed, 25 Aug 2004 13:45:31 -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 i7PHiA933918; Wed, 25 Aug 2004 10:44: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 i7PHi5e75971; Wed, 25 Aug 2004 10:44:05 -0700 (PDT) (envelope-from ina@juniper.net) Date: Wed, 25 Aug 2004 10:44:05 -0700 (PDT) From: Ina Minei To: Eric Rosen Subject: Re: [mpls] Requesting your feedback - issues/errors/clarifications In-Reply-To: <200408251500.i7PF0HjF028378@rtp-core-1.cisco.com> Message-ID: <20040825103122.U68808@garnet.juniper.net> References: <200408251500.i7PF0HjF028378@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: mpls@ietf.org, vach.kompella@alcatel.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: ea4ac80f790299f943f0a53be7e1a21a > > > Issue: do we really have to send all FECs in our database whenever we > > have an LDP session between two peers? > > This should not be a requirement of the protocol spec, the application which > is using the protocol should determine which FECS get sent. I agree. This is not a specification issue, but rather a best-practice based on the application for which the protocol is used. If you only need the loopbacks as FECs for your application, then it is best if you _ask_ LDP to only redistribute the loopbacks, because it will make your network easier to troubleshoot. Ina > > > Issue: with all the combinations of Downstream Unsolicited, Downstream > > on Demand, Ordered Control, Independent Control, etc., it makes sense to > > define a mandatory combination. DU/OC seems to be the favored one. > > I believe this would put a majority of the deployed LDP speakers out of > spec. Such a change cannot be made as part of going to DS. > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Aug 26 16:43: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 QAA09981; Thu, 26 Aug 2004 16:43:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0R6W-0007HG-CI; Thu, 26 Aug 2004 16:44:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0QrI-0004lg-Aa; Thu, 26 Aug 2004 16:28:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0Qje-0007Lf-5v for mpls@megatron.ietf.org; Thu, 26 Aug 2004 16:20: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 QAA07652 for ; Thu, 26 Aug 2004 16:20:36 -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 1C0Qkd-0006a7-Cc for mpls@ietf.org; Thu, 26 Aug 2004 16:21:40 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 26 Aug 2004 13:26:59 +0000 X-BrightmailFiltered: true Received: from [128.107.176.171] (dhcp-128-107-176-171.cisco.com [128.107.176.171]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7QKK06B029837; Thu, 26 Aug 2004 13:20:00 -0700 (PDT) Message-ID: <412E53C4.1030100@cisco.com> Date: Thu, 26 Aug 2004 15:19:00 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: Italian [it], French/Canada [fr-CA], French/France [fr-FR], English/United States [en-US] MIME-Version: 1.0 To: Ina Minei Subject: Re: [mpls] Requesting your feedback - issues/errors/clarifications References: <200408251500.i7PF0HjF028378@rtp-core-1.cisco.com> <20040825103122.U68808@garnet.juniper.net> In-Reply-To: <20040825103122.U68808@garnet.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, vach.kompella@alcatel.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: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Ina, Please note the following points: - the LDP loop detection mechanisms do not make much sense in DU mode. This is the hop count TLV, and the Path Vector TLV. ( When LDP interoperability testing was just starting , I had most vendors out there remove it for DU mode ). 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 ) - The Host FEC is accepted by most implementations I worked with , but sent by none. So I also think it's probably a good idea to remove it. Luca Ina Minei wrote: >>>Issue: do we really have to send all FECs in our database whenever we >>>have an LDP session between two peers? >>> >>> >>This should not be a requirement of the protocol spec, the application which >>is using the protocol should determine which FECS get sent. >> >> > > I agree. This is not a specification issue, but rather a >best-practice based on the application for which the protocol is used. >If you only need the loopbacks as FECs for your application, then it is >best if you _ask_ LDP to only redistribute the loopbacks, because it will >make your network easier to troubleshoot. > > Ina > > > > >>>Issue: with all the combinations of Downstream Unsolicited, Downstream >>>on Demand, Ordered Control, Independent Control, etc., it makes sense to >>>define a mandatory combination. DU/OC seems to be the favored one. >>> >>> >>I believe this would put a majority of the deployed LDP speakers out of >>spec. Such a change cannot be made as part of going to DS. >> >> >> > >_______________________________________________ >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 Aug 26 17:44: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 RAA15321; Thu, 26 Aug 2004 17:44:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0S3d-0000RZ-5N; Thu, 26 Aug 2004 17:45:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0Rv3-0000os-MS; Thu, 26 Aug 2004 17:36:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0Rcs-0005B3-03 for mpls@megatron.ietf.org; Thu, 26 Aug 2004 17:17: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 RAA13506 for ; Thu, 26 Aug 2004 17:17:27 -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 1C0Rdf-0008Gm-Bb for mpls@ietf.org; Thu, 26 Aug 2004 17:18:32 -0400 Received: from elmo.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id OAA05601; Thu, 26 Aug 2004 14:16:45 -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 i7QLGiR04783; Thu, 26 Aug 2004 14:16:44 -0700 (PDT) Message-ID: <412E533C.60003@riverstonenet.com> Date: Thu, 26 Aug 2004 14:16:44 -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: Ina Minei Subject: Re: [mpls] Requesting your feedback - issues/errors/clarifications References: <200408251500.i7PF0HjF028378@rtp-core-1.cisco.com> <20040825103122.U68808@garnet.juniper.net> <412E53C4.1030100@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, vach.kompella@alcatel.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: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Hi, I also think that removing Host FEC is a good idea Regards, Rama Ramakrishnan Luca Martini wrote: > Ina, > > Please note the following points: > > - the LDP loop detection mechanisms do not make much sense in DU mode. > This is the hop count TLV, and the Path Vector TLV. ( When LDP > interoperability testing was just starting , I had most vendors out > there remove it for DU mode ). 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 ) > > - The Host FEC is accepted by most implementations I worked with , but > sent by none. So I also think it's probably a good idea to remove it. > > Luca > > > > Ina Minei wrote: > >>>> Issue: do we really have to send all FECs in our database whenever we >>>> have an LDP session between two peers? >>>> >>> >>> This should not be a requirement of the protocol spec, the >>> application which >>> is using the protocol should determine which FECS get sent. >>> >> >> >> I agree. This is not a specification issue, but rather a >> best-practice based on the application for which the protocol is used. >> If you only need the loopbacks as FECs for your application, then it is >> best if you _ask_ LDP to only redistribute the loopbacks, because it will >> make your network easier to troubleshoot. >> >> Ina >> >> >> >> >>>> Issue: with all the combinations of Downstream Unsolicited, Downstream >>>> on Demand, Ordered Control, Independent Control, etc., it makes >>>> sense to >>>> define a mandatory combination. DU/OC seems to be the favored one. >>>> >>> >>> I believe this would put a majority of the deployed LDP speakers >>> out of >>> spec. Such a change cannot be made as part of going to DS. >>> >>> >> >> >> _______________________________________________ >> 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 Sun Aug 29 07:12: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 HAA00459; Sun, 29 Aug 2004 07:12:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1NdN-00004r-Mu; Sun, 29 Aug 2004 07:14:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1NSp-0000ic-Nn; Sun, 29 Aug 2004 07:03:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1JWZ-00027y-2D for mpls@megatron.ietf.org; Sun, 29 Aug 2004 02:50:47 -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 CAA20726 for ; Sun, 29 Aug 2004 02:50:44 -0400 (EDT) From: AtrJoh@netscape.net Received: from AtrJoh@netscape.net by imo-d01.mx.aol.com (mail_out_v37_r3.4.) id n.1af.bae1db3 (16239) for ; Sun, 29 Aug 2004 02:50:13 -0400 (EDT) Received: from netscape.net (mow-d16.webmail.aol.com [205.188.139.132]) by air-in03.mx.aol.com (v101.19) with ESMTP id MAILININ33-3f6f41317ca4fe; Sun, 29 Aug 2004 02:50:13 -0400 Date: Sun, 29 Aug 2004 02:50:12 -0400 To: mpls@ietf.org MIME-Version: 1.0 Message-ID: <417C6658.3CD20D62.00047620@netscape.net> X-Mailer: Atlas Mailer 2.0 X-AOL-IP: 62.90.130.2 X-AOL-Language: english Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sun, 29 Aug 2004 07:03:10 -0400 Subject: [mpls] Processing of RESV message 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: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 8bit 1. Is it possible to reserve less than requested in the flow-info without failing? If yes what should be forwarded to the upstream node? 2. What should be forwarded to the upstream node in case the peak data rate, which was received in flow was "positive inf"? Thanks, Joh __________________________________________________________________ Switch to Netscape Internet Service. As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register Netscape. Just the Net You Need. New! Netscape Toolbar for Internet Explorer Search from anywhere on the Web and block those annoying pop-ups. Download now at http://channels.netscape.com/ns/search/install.jsp _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Aug 30 10:00: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 KAA24738; Mon, 30 Aug 2004 10:00:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1mk7-0004qS-4f; Mon, 30 Aug 2004 10:02:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1meP-0005vK-Tj; Mon, 30 Aug 2004 09:56:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1mVy-0004Sw-1p for mpls@megatron.ietf.org; Mon, 30 Aug 2004 09:48:06 -0400 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23984 for ; Mon, 30 Aug 2004 09:48:02 -0400 (EDT) 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 i7UDlXxX006165 for ; Mon, 30 Aug 2004 09:47:33 -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 JAA24789 for ; Mon, 30 Aug 2004 09:47:33 -0400 (EDT) Message-ID: <41332F8D.6040901@marconi.com> Date: Mon, 30 Aug 2004 09:45:49 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: [mpls] Processing of RESV message References: <417C6658.3CD20D62.00047620@netscape.net> In-Reply-To: <417C6658.3CD20D62.00047620@netscape.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit AtrJoh@netscape.net wrote: > 1. Is it possible to reserve less than requested in the flow-info > without failing? If yes what should be forwarded to the upstream > node? Yes, it is theoretically possible. In RSVP (including RSVP-TE), the egress node decides what should go in the FLOWSPEC. It may choose any amount of resources between zero and the least-upper-bound of the TSPEC and ADSPEC. Larger values are legal, but the transit nodes will clip them to the TSPEC value, and they may result in admission-control errors if the resources are unavailable (which is what the ADSPEC is supposed to inform the egress node.) In actual practice, with RSVP-TE, the value placed in the FLOWSPEC will be directly taken from the TSPEC. This is because RSVP-TE is a router-to-router protocol. An egress node generally will not be able to determine what (if any) smaller-size reservations might be acceptable to the application(s) that will ultimately be using the LSP. (This is different from classical RSVP. In classical RSVP, the signaling goes from application to application, so an egress node may have sufficient information to pick a smaller acceptable value.) In terms of what this reduced-size reservation looks like, it is exactly like any other Resv message, but with less resources represented in the FLOWSPEC object. > 2. What should be forwarded to the upstream node in case the peak > data rate, which was received in flow was "positive inf"? If your egress node is going to start picking alternate QoS values, it will be up to that node to somehow try and figure out what values to use. A positive-infinity value for a peak data rate effectively means "no limit - peak at everything available." If you choose to reduce it to something else, a good first guess might be the available bandwidth reported by the ADSPEC object. But unless your egress node has application-specific information, anything you generate has a good chance of being wrong. -- David _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Aug 30 12:14: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 MAA04872; Mon, 30 Aug 2004 12:14:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1opO-0007eI-JW; Mon, 30 Aug 2004 12:16:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1ocB-0003Bq-27; Mon, 30 Aug 2004 12:02:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1oXU-0002Sb-4V for mpls@megatron.ietf.org; Mon, 30 Aug 2004 11:57: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 LAA03908 for ; Mon, 30 Aug 2004 11:57:45 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1oZH-0007Hw-Cl for mpls@ietf.org; Mon, 30 Aug 2004 11:59:39 -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 i7UFvFB17148 for ; Mon, 30 Aug 2004 11:57:15 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Aug 2004 11:57:14 -0400 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE17ED8D@zcarhxm2.corp.nortel.com> From: "Arashmid Akhavain" To: mpls@ietf.org Subject: RE: [mpls] Requesting your feedback - issues/errors/clarification s Date: Mon, 30 Aug 2004 11:57:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.9 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 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="===============0921775444==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd 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. --===============0921775444== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48EAA.0073F34F" 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_01C48EAA.0073F34F Content-Type: text/plain Please see my comments below: + I agree with Luca. I have not seen much use for loop detection in DU mode of operation. So, it would be nice to either clarify its use. + I also agree with removal of the HOST FECs. Although they are + supported by the protocol, I have not seen them being advertised. + I agree that the selection of FECs for which LDP sends label mapping + message should not be a requirements of the protocol spec. The FECs should be either determined by the applications as Ina mentioned, or controlled via policies. + As for the use of DU in conjunction with independent control mode of + operation, I agree with Vach that DU and IC can result in black holes or packet misrouting in the network. The scheme works fine for IP forwarding, but as Vach pointed out in his e-mail, it creates issues in VPN networks. Arashmid -----Original Message----- From: Luca Martini [mailto:lmartini@cisco.com ] Sent: Thursday, August 26, 2004 5:19 PM To: Ina Minei Cc: mpls@ietf.org; vach.kompella@alcatel.com Subject: Re: [mpls] Requesting your feedback - issues/errors/clarifications Ina, Please note the following points: - the LDP loop detection mechanisms do not make much sense in DU mode. This is the hop count TLV, and the Path Vector TLV. ( When LDP interoperability testing was just starting , I had most vendors out there remove it for DU mode ). 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 ) - The Host FEC is accepted by most implementations I worked with , but sent by none. So I also think it's probably a good idea to remove it. Luca Ina Minei wrote: >>>Issue: do we really have to send all FECs in our database whenever we >>>have an LDP session between two peers? >>> >>> >>This should not be a requirement of the protocol spec, the application >>which is using the protocol should determine which FECS get sent. >> >> > > I agree. This is not a specification issue, but rather a best-practice >based on the application for which the protocol is used. If you only >need the loopbacks as FECs for your application, then it is best if you >_ask_ LDP to only redistribute the loopbacks, because it will make your >network easier to troubleshoot. > > Ina > > > > >>>Issue: with all the combinations of Downstream Unsolicited, >>>Downstream on Demand, Ordered Control, Independent Control, etc., it >>>makes sense to define a mandatory combination. DU/OC seems to be the >>>favored one. >>> >>> >>I believe this would put a majority of the deployed LDP speakers >>out of spec. Such a change cannot be made as part of going to DS. >> >> >> > >_______________________________________________ >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 ------_=_NextPart_001_01C48EAA.0073F34F Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mpls] Requesting your feedback - = issues/errors/clarifications

Please see my comments = below:


+ I agree with Luca. I have not = seen much use for loop detection in
  DU mode of operation. = So, it would be nice to either clarify its use.

+ I also agree with removal of = the HOST FECs. Although they are
+ supported
  by the protocol, I have = not seen them being advertised.

+ I agree that the selection of = FECs for which LDP sends label mapping
+ message
  should not be a = requirements of the protocol spec. The FECs should be either
  determined by the = applications as Ina mentioned, or controlled via policies.

+ As for the use of DU in = conjunction with independent control mode of
+ operation,
  I agree with Vach that = DU and IC can result in black holes or packet misrouting
  in the network. The = scheme works fine for IP forwarding, but as Vach pointed out
  in his e-mail, it = creates issues in VPN networks.


Arashmid

-----Original = Message-----
From: Luca Martini [mailto:lmartini@cisco.com]
Sent: Thursday, August 26, 2004 = 5:19 PM
To: Ina Minei
Cc: mpls@ietf.org; = vach.kompella@alcatel.com
Subject: Re: [mpls] Requesting = your feedback - issues/errors/clarifications


Ina,

Please note the following = points:

- the LDP loop detection = mechanisms do not make much sense in DU mode.
This is the hop count = TLV,  and the Path Vector TLV. ( When LDP
interoperability testing was = just starting , I had most vendors out
there remove it for DU mode ). = 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 )

- The Host FEC is accepted by = most implementations I worked with , but
sent by none. So I also think = it's probably a good idea to remove it.

Luca



Ina Minei wrote:

>>>Issue: do we really = have to send all FECs in our database whenever we
>>>have an LDP session = between two peers?
>>>     
>>>
>>This should not be a = requirement of the protocol spec, the application
>>which is using the = protocol should determine which FECS get sent.
>>    =
>>
>
>       I agree. This is not a = specification issue, but rather a best-practice
>based on the application = for which the protocol is used. If you only
>need the loopbacks as FECs = for your application, then it is best if you
>_ask_ LDP to only = redistribute the loopbacks, because it will make your
>network easier to = troubleshoot.
>
>       =         =         =         Ina
>
>
> 
>
>>>Issue: with all the = combinations of Downstream Unsolicited,
>>>Downstream on = Demand, Ordered Control, Independent Control, etc., it
>>>makes sense to = define a mandatory combination.  DU/OC seems to be the
>>>favored one.
>>>     
>>>
>>I believe  this = would  put a majority  of the  deployed LDP = speakers
>>out of spec.  Such = a change cannot be made as part of going to DS.
>>
>>    =
>>
>
>_______________________________________________
>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


------_=_NextPart_001_01C48EAA.0073F34F-- --===============0921775444== 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 --===============0921775444==-- From mpls-bounces@ietf.org Mon Aug 30 12:18: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 MAA05266; Mon, 30 Aug 2004 12:18:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1ot1-0007jA-0v; Mon, 30 Aug 2004 12:20:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1onD-0008E0-V7; Mon, 30 Aug 2004 12:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1obV-000383-2J for mpls@megatron.ietf.org; Mon, 30 Aug 2004 12:01: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 MAA04106 for ; Mon, 30 Aug 2004 12:01:54 -0400 (EDT) Received: from imo-d02.mx.aol.com ([205.188.157.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1odF-0007OT-2H for mpls@ietf.org; Mon, 30 Aug 2004 12:03:48 -0400 Received: from balavenkata@netscape.net by imo-d02.mx.aol.com (mail_out_v37_r3.4.) id v.2a.e0b97a4 (16237); Mon, 30 Aug 2004 12:01:18 -0400 (EDT) Received: from [192.168.1.250] ([67.50.107.71]) by air-in03.mx.aol.com (v101.19) with ESMTP id MAILININ31-3f6d41334f4425a; Mon, 30 Aug 2004 12:01:17 -0400 Message-ID: <41335130.6020408@netscape.net> Date: Mon, 30 Aug 2004 09:09:20 -0700 From: Bala Venkata User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: adrian@olddog.co.uk References: <410EE3DA.7090306@netscape.net> <011701c47904$7d25b5f0$54808182@Puppy> <41100149.5050107@netscape.net> In-Reply-To: <41100149.5050107@netscape.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 67.50.107.71 X-Mailer: Unknown (No Version) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, jvasseur@cisco.com Subject: [mpls] PCE WG X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Are there any updates on the PCE WG formation front ? After the BOF session meeting minutes we didn't hear anything further...just curious as to what the status is. Thanks ! /bala _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Aug 30 12: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 MAA06958; Mon, 30 Aug 2004 12:41:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1pFd-0008Bf-RX; Mon, 30 Aug 2004 12:43:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1p4c-000350-Qz; Mon, 30 Aug 2004 12:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1oxb-0002EB-5w for mpls@megatron.ietf.org; Mon, 30 Aug 2004 12:24: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 MAA05736 for ; Mon, 30 Aug 2004 12:24:44 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1ozO-0007pF-0i for mpls@ietf.org; Mon, 30 Aug 2004 12:26:39 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 30 Aug 2004 09:30:13 -0700 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 i7UGNxpf026877; Mon, 30 Aug 2004 09:24:05 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (che-vpn-cluster-2-65.cisco.com [10.86.242.65]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA00271; Mon, 30 Aug 2004 09:24:00 -0700 (PDT) Message-Id: <4.3.2.7.2.20040830122021.06e8ca10@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 30 Aug 2004 12:23:58 -0400 To: Bala Venkata From: Jean Philippe Vasseur In-Reply-To: <41335130.6020408@netscape.net> References: <41100149.5050107@netscape.net> <410EE3DA.7090306@netscape.net> <011701c47904$7d25b5f0$54808182@Puppy> <41100149.5050107@netscape.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: mpls@ietf.org Subject: [mpls] Re: PCE WG 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: 0bc60ec82efc80c84b8d02f4b0e4de22 Hi Bala, At 09:09 AM 8/30/2004 -0700, Bala Venkata wrote: >Are there any updates on the PCE WG formation front ? >After the BOF session meeting minutes we didn't hear >anything further...just curious as to what the status >is. We'll send the minutes very shortly. The creation of a PCE mailing list has been approved by Alex/Bill and should be done soon. As requested by Alex, the first goal will be to prepare an architecture ID which will be discussed soon on the mailing list. Thanks. JP. >Thanks ! > >/bala > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Aug 30 12:59: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 MAA08480; Mon, 30 Aug 2004 12:59:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1pXA-00008q-SJ; Mon, 30 Aug 2004 13:01:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1pT6-0007Uk-Ko; Mon, 30 Aug 2004 12:57:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1pJi-0005Z2-Lz for mpls@megatron.ietf.org; Mon, 30 Aug 2004 12:47: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 MAA07608 for ; Mon, 30 Aug 2004 12:47:32 -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 1C1pLS-0008J0-Du for mpls@ietf.org; Mon, 30 Aug 2004 12:49:27 -0400 Received: from elmo.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id JAA04712; Mon, 30 Aug 2004 09:47:02 -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 i7UGl1R05524; Mon, 30 Aug 2004 09:47:01 -0700 (PDT) Message-ID: <41335A04.2050906@riverstonenet.com> Date: Mon, 30 Aug 2004 09:47:00 -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: Ina Minei Subject: Re: [mpls] Requesting your feedback - issues/errors/clarifications References: <200408251500.i7PF0HjF028378@rtp-core-1.cisco.com> <20040825103122.U68808@garnet.juniper.net> <412E53C4.1030100@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Ina, I tried to go through the LDP RFC to see if it specifically says that a wildcard release message should be sent only in response to a wildcard withdraw message. There may be a timing condition in which an upstream router may still hold a label for which downstream router has removed it from the incoming label database. draft-ietf-pwe3-control-protocol-08.txt probably talks about a similar situation for wildcard release for L2 FECs as below "A wildcard release message MUST include only the group ID. A Label Release message initiated from the imposition router must always include the PW ID." Any thoughts? Regards, Rama Ramakrishnan _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Aug 30 13: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 NAA09753; Mon, 30 Aug 2004 13:14:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1plr-0000UV-1h; Mon, 30 Aug 2004 13:16:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1phE-0001ZR-N9; Mon, 30 Aug 2004 13:11:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1pU2-0007g6-EB for mpls@megatron.ietf.org; Mon, 30 Aug 2004 12:58: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 MAA08359 for ; Mon, 30 Aug 2004 12:58:15 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1pVq-00005x-CM for mpls@ietf.org; Mon, 30 Aug 2004 13:00:10 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 30 Aug 2004 13:09:55 -0400 X-BrightmailFiltered: true Received: from cisco.com (rhthomas-u10.cisco.com [161.44.71.42]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7UGvjZQ013659; Mon, 30 Aug 2004 12:57:45 -0400 (EDT) Message-Id: <200408301657.i7UGvjZQ013659@rtp-core-2.cisco.com> To: "Arashmid Akhavain" Subject: Re: [mpls] Requesting your feedback - issues/errors/clarification s In-Reply-To: Message from "Arashmid Akhavain" of "Mon, 30 Aug 2004 11:57:07 EDT." <87AC5F88F03E6249AEA68D40BD3E00BE17ED8D@zcarhxm2.corp.nortel.com> Date: Mon, 30 Aug 2004 12:57:45 -0400 From: Bob Thomas X-Spam-Score: 1.1 (+) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e 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: 1.1 (+) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 > Please see my comments below: > > > + I agree with Luca. I have not seen much use for loop detection in > DU mode of operation. So, it would be nice to either clarify its use. > > + I also agree with removal of the HOST FECs. Although they are > + supported > by the protocol, I have not seen them being advertised. > > + I agree that the selection of FECs for which LDP sends label mapping > + message > should not be a requirements of the protocol spec. The FECs should be > either > determined by the applications as Ina mentioned, or controlled via > policies. > > + As for the use of DU in conjunction with independent control mode of > + operation, > I agree with Vach that DU and IC can result in black holes or packet > misrouting How does it result in "misrouting"? > in the network. The scheme works fine for IP forwarding, but as Vach > pointed out > in his e-mail, it creates issues in VPN networks. It seems to me that the appropriate place to address this issue is in the protocol applicability document (i.e., rfc3037 as opposed to rfc3036). Bob > Arashmid > > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com ] > Sent: Thursday, August 26, 2004 5:19 PM > To: Ina Minei > Cc: mpls@ietf.org; vach.kompella@alcatel.com > Subject: Re: [mpls] Requesting your feedback - issues/errors/clarifications > > > Ina, > > Please note the following points: > > - the LDP loop detection mechanisms do not make much sense in DU mode. > This is the hop count TLV, and the Path Vector TLV. ( When LDP > interoperability testing was just starting , I had most vendors out > there remove it for DU mode ). 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 ) > > - The Host FEC is accepted by most implementations I worked with , but > sent by none. So I also think it's probably a good idea to remove it. > > Luca > > > > Ina Minei wrote: > > >>>Issue: do we really have to send all FECs in our database whenever we > >>>have an LDP session between two peers? > >>> > >>> > >>This should not be a requirement of the protocol spec, the application > >>which is using the protocol should determine which FECS get sent. > >> > >> > > > > I agree. This is not a specification issue, but rather a > best-practice > >based on the application for which the protocol is used. If you only > >need the loopbacks as FECs for your application, then it is best if you > >_ask_ LDP to only redistribute the loopbacks, because it will make your > >network easier to troubleshoot. > > > > Ina > > > > > > > > > >>>Issue: with all the combinations of Downstream Unsolicited, > >>>Downstream on Demand, Ordered Control, Independent Control, etc., it > >>>makes sense to define a mandatory combination. DU/OC seems to be the > >>>favored one. > >>> > >>> > >>I believe this would put a majority of the deployed LDP speakers > >>out of spec. Such a change cannot be made as part of going to DS. > >> > >> > >> > > > >_______________________________________________ > >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 > > > > > ------_=_NextPart_001_01C48EAA.0073F34F > Content-Type: text/html > Content-Transfer-Encoding: quoted-printable > > > > > charset=3Dus-ascii"> > 5.5.2656.31"> > RE: [mpls] Requesting your feedback - = > issues/errors/clarifications > > >
> >

Please see my comments = > below: >

>
> >

+ I agree with Luca. I have not = > seen much use for loop detection in >
  DU mode of operation. = > So, it would be nice to either clarify its use. >

> >

+ I also agree with removal of = > the HOST FECs. Although they are >
+ supported >
  by the protocol, I have = > not seen them being advertised. >

> >

+ I agree that the selection of = > FECs for which LDP sends label mapping >
+ message >
  should not be a = > requirements of the protocol spec. The FECs should be either >
  determined by the = > applications as Ina mentioned, or controlled via policies. >

> >

+ As for the use of DU in = > conjunction with independent control mode of >
+ operation, >
  I agree with Vach that = > DU and IC can result in black holes or packet misrouting >
  in the network. The = > scheme works fine for IP forwarding, but as Vach pointed out >
  in his e-mail, it = > creates issues in VPN networks. >

>
> >

Arashmid >

> >

-----Original = > Message----- >
From: Luca Martini [ HREF=3D"mailto:lmartini@cisco.com"> FACE=3D"Courier New">mailto:lmartini@cisco.com SIZE=3D2 FACE=3D"Courier New">] >
Sent: Thursday, August 26, 2004 = > 5:19 PM >
To: Ina Minei >
Cc: mpls@ietf.org; = > vach.kompella@alcatel.com >
Subject: Re: [mpls] Requesting = > your feedback - issues/errors/clarifications >

>
> >

Ina, >

> >

Please note the following = > points: >

> >

- the LDP loop detection = > mechanisms do not make much sense in DU mode. >
This is the hop count = > TLV,  and the Path Vector TLV. ( When LDP >
interoperability testing was = > just starting , I had most vendors out >
there remove it for DU mode ). = > 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 ) >

> >

- The Host FEC is accepted by = > most implementations I worked with , but >
sent by none. So I also think = > it's probably a good idea to remove it. >

> >

Luca >

>
>
> >

Ina Minei wrote: >

> >

>>>Issue: do we really = > have to send all FECs in our database whenever we >
>>>have an LDP session = > between two peers? >
New">>>>      >
>>> >
>>This should not be a = > requirement of the protocol spec, the application >
>>which is using the = > protocol should determine which FECS get sent. >
>>    = > >
>> >
> >
New">>       I agree. This is not a = > specification issue, but rather a best-practice >
>based on the application = > for which the protocol is used. If you only >
>need the loopbacks as FECs = > for your application, then it is best if you >
>_ask_ LDP to only = > redistribute the loopbacks, because it will make your >
>network easier to = > troubleshoot. >
> >
New">>       = >         = >         = >         Ina >
> >
> >
>  >
> >
>>>Issue: with all the = > combinations of Downstream Unsolicited, >
>>>Downstream on = > Demand, Ordered Control, Independent Control, etc., it >
>>>makes sense to = > define a mandatory combination.  DU/OC seems to be the >
>>>favored one. >
New">>>>      >
>>> >
>>I believe  this = > would  put a majority  of the  deployed LDP = > speakers >
>>out of spec.  Such = > a change cannot be made as part of going to DS. >
>> >
>>    = > >
>> >
> >
New">>_______________________________________________ >
>mpls mailing list >
>mpls@lists.ietf.org = > COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier = > New">https://www1.ietf.org/mailman/listinfo/mpls >
> >
>  >
> >

>
> >

New">_______________________________________________ >
mpls mailing list >
mpls@lists.ietf.org >
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier = > New">https://www1.ietf.org/mailman/listinfo/mpls >

>
> > > > ------_=_NextPart_001_01C48EAA.0073F34F-- > > > --===============0921775444== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > > --===============0921775444==-- > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Aug 30 17:30: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 RAA04750; Mon, 30 Aug 2004 17:30:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1tlc-0000Il-4r; Mon, 30 Aug 2004 17:32:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1tT1-0002QL-SU; Mon, 30 Aug 2004 17:13:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1tCO-0003Qp-V9 for mpls@megatron.ietf.org; Mon, 30 Aug 2004 16:56: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 QAA00855 for ; Mon, 30 Aug 2004 16:56:18 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1tED-0007Ox-EX for mpls@ietf.org; Mon, 30 Aug 2004 16:58:15 -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 i7UKs4P20982; Mon, 30 Aug 2004 16:54:04 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Aug 2004 16:54:03 -0400 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE17ED90@zcarhxm2.corp.nortel.com> From: "Arashmid Akhavain" To: "'Bob Thomas'" Subject: RE: [mpls] Requesting your feedback - issues/errors/clarification s Date: Mon, 30 Aug 2004 16:53:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: 731ea0e9f5725b67e634db1918f3b951 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="===============1642099995==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d 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. --===============1642099995== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48ED3.76CACD33" 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_01C48ED3.76CACD33 Content-Type: text/plain Packet misrouting can happen under the following circumstance. Consider the following L3-VPN network A----------B----- ... ------Z + B sends a label mapping message for loop back address of Z to A using the independent control mode of operation. Let's call this label L10. + Z advertises label L100 for one of its VPN routes to A via MP-BGP. + B could also be a PE and could have allocated label value L100 to one of its links to a CE device it is connecting to. + Receiving L10 for the loop back address of Z, A will be under the + impression that it has a full path to Z. + A starts transmitting packets with outer label L10 and inner label + L100. Meanwhile no label representing the loop back address of Z has arrived at B. + B receives the labeled packet and pops L10. + B then proceeds with the processing of L100. + B recognizes L100 as a local label and transmits the un labeled packet + to the wrong CE device. Arashmid -----Original Message----- From: Bob Thomas [mailto:rhthomas@cisco.com] Sent: Monday, August 30, 2004 12:58 PM To: Akhavain, Arashmid [CAR:NP62:EXCH] Cc: mpls@ietf.org Subject: Re: [mpls] Requesting your feedback - issues/errors/clarification s > Please see my comments below: > > > + I agree with Luca. I have not seen much use for loop detection in > DU mode of operation. So, it would be nice to either clarify its > use. > > + I also agree with removal of the HOST FECs. Although they are > + supported > by the protocol, I have not seen them being advertised. > > + I agree that the selection of FECs for which LDP sends label mapping > + message > should not be a requirements of the protocol spec. The FECs should > be either > determined by the applications as Ina mentioned, or controlled via > policies. > > + As for the use of DU in conjunction with independent control mode of > + operation, > I agree with Vach that DU and IC can result in black holes or packet > misrouting How does it result in "misrouting"? > in the network. The scheme works fine for IP forwarding, but as Vach > pointed out > in his e-mail, it creates issues in VPN networks. It seems to me that the appropriate place to address this issue is in the protocol applicability document (i.e., rfc3037 as opposed to rfc3036). Bob > Arashmid > > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com > ] > Sent: Thursday, August 26, 2004 5:19 PM > To: Ina Minei > Cc: mpls@ietf.org; vach.kompella@alcatel.com > Subject: Re: [mpls] Requesting your feedback - issues/errors/clarifications > > > Ina, > > Please note the following points: > > - the LDP loop detection mechanisms do not make much sense in DU mode. > This is the hop count TLV, and the Path Vector TLV. ( When LDP > interoperability testing was just starting , I had most vendors out > there remove it for DU mode ). 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 ) > > - The Host FEC is accepted by most implementations I worked with , but > sent by none. So I also think it's probably a good idea to remove it. > > Luca > > > > Ina Minei wrote: > > >>>Issue: do we really have to send all FECs in our database whenever > >>>we have an LDP session between two peers? > >>> > >>> > >>This should not be a requirement of the protocol spec, the > >>application which is using the protocol should determine which FECS > >>get sent. > >> > >> > > > > I agree. This is not a specification issue, but rather a > best-practice > >based on the application for which the protocol is used. If you only > >need the loopbacks as FECs for your application, then it is best if > >you _ask_ LDP to only redistribute the loopbacks, because it will > >make your network easier to troubleshoot. > > > > Ina > > > > > > > > > >>>Issue: with all the combinations of Downstream Unsolicited, > >>>Downstream on Demand, Ordered Control, Independent Control, etc., > >>>it makes sense to define a mandatory combination. DU/OC seems to > >>>be the favored one. > >>> > >>> > >>I believe this would put a majority of the deployed LDP speakers > >>out of spec. Such a change cannot be made as part of going to DS. > >> > >> > >> > > > >_______________________________________________ > >mpls mailing list > >mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls > > > > > > > > ------_=_NextPart_001_01C48ED3.76CACD33 Content-Type: text/html RE: [mpls] Requesting your feedback - issues/errors/clarification s

Packet misrouting can happen under the following circumstance.
Consider the following L3-VPN network


A----------B----- ... ------Z

+ B sends a label mapping message for loop back address of Z to A using
  the independent control mode of operation. Let's call this label L10.

+ Z advertises label L100 for one of its VPN routes to A via MP-BGP.

+ B could also be a PE and could have allocated label value L100
  to one of its links to a CE device it is connecting to.

+ Receiving L10 for the loop back address of Z, A will be under the
+ impression
  that it has a full path to Z.

+ A starts transmitting packets with outer label L10 and inner label
+ L100. Meanwhile
  no label representing the loop back address of Z has arrived at B.

+ B receives the labeled packet and pops L10.

+ B then proceeds with the processing of L100.

+ B recognizes L100 as a local label and transmits the un labeled packet
+ to the
  wrong CE device.

Arashmid


-----Original Message-----
From: Bob Thomas [mailto:rhthomas@cisco.com]
Sent: Monday, August 30, 2004 12:58 PM
To: Akhavain, Arashmid [CAR:NP62:EXCH]
Cc: mpls@ietf.org
Subject: Re: [mpls] Requesting your feedback - issues/errors/clarification s


> Please see my comments below:
>
>
> + I agree with Luca. I have not seen much use for loop detection in
>   DU mode of operation. So, it would be nice to either clarify its
> use.
>
> + I also agree with removal of the HOST FECs. Although they are
> + supported
>   by the protocol, I have not seen them being advertised.
>
> + I agree that the selection of FECs for which LDP sends label mapping
> + message
>   should not be a requirements of the protocol spec. The FECs should
> be either
>   determined by the applications as Ina mentioned, or controlled via
> policies.
>
> + As for the use of DU in conjunction with independent control mode of
> + operation,
>   I agree with Vach that DU and IC can result in black holes or packet
> misrouting

How does it result in "misrouting"?


>   in the network. The scheme works fine for IP forwarding, but as Vach
> pointed out
>   in his e-mail, it creates issues in VPN networks.

It seems to me that the appropriate place to address this issue is in the protocol applicability document (i.e., rfc3037 as opposed to rfc3036).

Bob


> Arashmid
>
> -----Original Message-----
> From: Luca Martini [mailto:lmartini@cisco.com
> <mailto:lmartini@cisco.com> ]
> Sent: Thursday, August 26, 2004 5:19 PM
> To: Ina Minei
> Cc: mpls@ietf.org; vach.kompella@alcatel.com
> Subject: Re: [mpls] Requesting your feedback - issues/errors/clarifications
>
>
> Ina,
>
> Please note the following points:
>
> - the LDP loop detection mechanisms do not make much sense in DU mode.
> This is the hop count TLV,  and the Path Vector TLV. ( When LDP
> interoperability testing was just starting , I had most vendors out
> there remove it for DU mode ). 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 )
>
> - The Host FEC is accepted by most implementations I worked with , but
> sent by none. So I also think it's probably a good idea to remove it.
>
> Luca
>
>
>
> Ina Minei wrote:
>
> >>>Issue: do we really have to send all FECs in our database whenever
> >>>we have an LDP session between two peers?
> >>>     
> >>>
> >>This should not be a requirement of the protocol spec, the
> >>application which is using the protocol should determine which FECS
> >>get sent.
> >>   
> >>
> >
> >     I agree. This is not a specification issue, but rather a
> best-practice
> >based on the application for which the protocol is used. If you only
> >need the loopbacks as FECs for your application, then it is best if
> >you _ask_ LDP to only redistribute the loopbacks, because it will
> >make your network easier to troubleshoot.
> >
> >                             Ina
> >
> >
> > 
> >
> >>>Issue: with all the combinations of Downstream Unsolicited,
> >>>Downstream on Demand, Ordered Control, Independent Control, etc.,
> >>>it makes sense to define a mandatory combination.  DU/OC seems to
> >>>be the favored one.
> >>>     
> >>>
> >>I believe  this would  put a majority  of the  deployed LDP speakers
> >>out of spec.  Such a change cannot be made as part of going to DS.
> >>
> >>   
> >>
> >
> >_______________________________________________
> >mpls mailing list
> >mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
> <https://www1.ietf.org/mailman/listinfo/mpls>
> >
> > 
> >
>

------_=_NextPart_001_01C48ED3.76CACD33-- --===============1642099995== 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 --===============1642099995==-- From mpls-bounces@ietf.org Tue Aug 31 00:35: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 AAA03020; Tue, 31 Aug 2004 00:35:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C20OC-0001Fk-Qb; Tue, 31 Aug 2004 00:37:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C20Hf-0006sO-Hi; Tue, 31 Aug 2004 00:30:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1seL-0004hP-Fv for mpls@megatron.ietf.org; Mon, 30 Aug 2004 16:21:09 -0400 Received: from web50806.mail.yahoo.com (web50806.mail.yahoo.com [206.190.38.115]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24577 for ; Mon, 30 Aug 2004 16:21:06 -0400 (EDT) Message-ID: <20040830202037.57898.qmail@web50806.mail.yahoo.com> Received: from [64.115.125.242] by web50806.mail.yahoo.com via HTTP; Mon, 30 Aug 2004 13:20:36 PDT Date: Mon, 30 Aug 2004 13:20:36 -0700 (PDT) From: Fugui Wang To: kireeti@juniper.net, swallow@cisco.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 31 Aug 2004 00:30:07 -0400 Cc: mpls@ietf.org Subject: [mpls] draft-ietf-mpls-lsp-ping-06.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hello Kireeti and George, In draft-ietf-mpls-lsp-ping-06.txt page 20, there is a paragraph saying: "In "traceroute" mode (fault isolation mode), the TTL is set successively to 1, 2, ..." Transit node is suppose to send an Echo Reply message back with Downstream Mapping object(s). However, I am just wondering: when the transit node receives an MPLS packet with TTL expiration, how would it know the MPLS payload (Echo Request in this case) is an IP packet(In general, payload could be IPv4, IPv6, Martini, etc)? If transit node does not know the MPLS payload, how could it assume that it is an IP/UDP packet and parse it as an Echo Request? Thanks, Fugui __________________________________ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Aug 31 07:16: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 HAA07260; Tue, 31 Aug 2004 07:16:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C26es-0000EE-0M; Tue, 31 Aug 2004 07: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 1C26bS-0001Ig-EC; Tue, 31 Aug 2004 07:15:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C26Qr-0000FN-1b for mpls@megatron.ietf.org; Tue, 31 Aug 2004 07:04:09 -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 HAA06591 for ; Tue, 31 Aug 2004 07:04:06 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C26So-0008Qg-Ri for mpls@ietf.org; Tue, 31 Aug 2004 07:06:11 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 31 Aug 2004 07:15:53 -0400 X-BrightmailFiltered: true Received: from cisco.com (rhthomas-u10.cisco.com [161.44.71.42]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7VB3aUu020080; Tue, 31 Aug 2004 07:03:36 -0400 (EDT) Message-Id: <200408311103.i7VB3aUu020080@rtp-core-1.cisco.com> To: "Arashmid Akhavain" Subject: Re: [mpls] Requesting your feedback - issues/errors/clarification s In-Reply-To: Message from "Arashmid Akhavain" of "Mon, 30 Aug 2004 16:53:55 EDT." <87AC5F88F03E6249AEA68D40BD3E00BE17ED90@zcarhxm2.corp.nortel.com> Date: Tue, 31 Aug 2004 07:03:35 -0400 From: Bob Thomas X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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: 3d7f2f6612d734db849efa86ea692407 > Packet misrouting can happen under the following circumstance. > Consider the following L3-VPN network > > > A----------B----- ... ------Z > > + B sends a label mapping message for loop back address of Z to A using > the independent control mode of operation. Let's call this label L10. > > + Z advertises label L100 for one of its VPN routes to A via MP-BGP. > > + B could also be a PE and could have allocated label value L100 > to one of its links to a CE device it is connecting to. > > + Receiving L10 for the loop back address of Z, A will be under the > impression > that it has a full path to Z. > > + A starts transmitting packets with outer label L10 and inner label L100. > Meanwhile > no label representing the loop back address of Z has arrived at B. > > + B receives the labeled packet and pops L10. > > + B then proceeds with the processing of L100. > > + B recognizes L100 as a local label and transmits the un labeled packet to > the > wrong CE device. This behavior of B appears to be in violation of the spirit (if not the letter) of the advice in Section 3.22 (Lack of Outgoing Label) of rfc3031. Unless label L10 refers to B itself (which it doesn't in the scenario described above), forwarding the packet according to the label beneath it (L100) is a forwarding error. Bob > Arashmid > > > -----Original Message----- > From: Bob Thomas [mailto:rhthomas@cisco.com] > Sent: Monday, August 30, 2004 12:58 PM > To: Akhavain, Arashmid [CAR:NP62:EXCH] > Cc: mpls@ietf.org > Subject: Re: [mpls] Requesting your feedback - issues/errors/clarification s > > > > > Please see my comments below: > > > > > > + I agree with Luca. I have not seen much use for loop detection in > > DU mode of operation. So, it would be nice to either clarify its > > use. > > > > + I also agree with removal of the HOST FECs. Although they are > > + supported > > by the protocol, I have not seen them being advertised. > > > > + I agree that the selection of FECs for which LDP sends label mapping > > + message > > should not be a requirements of the protocol spec. The FECs should > > be either > > determined by the applications as Ina mentioned, or controlled via > > policies. > > > > + As for the use of DU in conjunction with independent control mode of > > + operation, > > I agree with Vach that DU and IC can result in black holes or packet > > misrouting > > How does it result in "misrouting"? > > > > in the network. The scheme works fine for IP forwarding, but as Vach > > pointed out > > in his e-mail, it creates issues in VPN networks. > > It seems to me that the appropriate place to address this issue is in the > protocol applicability document (i.e., rfc3037 as opposed to rfc3036). > > Bob > > > > Arashmid > > > > -----Original Message----- > > From: Luca Martini [mailto:lmartini@cisco.com > > ] > > Sent: Thursday, August 26, 2004 5:19 PM > > To: Ina Minei > > Cc: mpls@ietf.org; vach.kompella@alcatel.com > > Subject: Re: [mpls] Requesting your feedback - > issues/errors/clarifications > > > > > > Ina, > > > > Please note the following points: > > > > - the LDP loop detection mechanisms do not make much sense in DU mode. > > This is the hop count TLV, and the Path Vector TLV. ( When LDP > > interoperability testing was just starting , I had most vendors out > > there remove it for DU mode ). 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 ) > > > > - The Host FEC is accepted by most implementations I worked with , but > > sent by none. So I also think it's probably a good idea to remove it. > > > > Luca > > > > > > > > Ina Minei wrote: > > > > >>>Issue: do we really have to send all FECs in our database whenever > > >>>we have an LDP session between two peers? > > >>> > > >>> > > >>This should not be a requirement of the protocol spec, the > > >>application which is using the protocol should determine which FECS > > >>get sent. > > >> > > >> > > > > > > I agree. This is not a specification issue, but rather a > > best-practice > > >based on the application for which the protocol is used. If you only > > >need the loopbacks as FECs for your application, then it is best if you > > >_ask_ LDP to only redistribute the loopbacks, because it will make your > > >network easier to troubleshoot. > > > > > > Ina > > > > > > > > > > > > > > >>>Issue: with all the combinations of Downstream Unsolicited, > > >>>Downstream on Demand, Ordered Control, Independent Control, etc., > > >>>it makes sense to define a mandatory combination. DU/OC seems to > > >>>be the favored one. > > >>> > > >>> > > >>I believe this would put a majority of the deployed LDP speakers > > >>out of spec. Such a change cannot be made as part of going to DS. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Aug 31 11:17: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 LAA24473; Tue, 31 Aug 2004 11:17:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2APt-0005fk-Tj; Tue, 31 Aug 2004 11:19:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2AJU-0001eb-5o; Tue, 31 Aug 2004 11:12:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2AHA-0001Cz-Uh for mpls@megatron.ietf.org; Tue, 31 Aug 2004 11:10: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 LAA24018 for ; Tue, 31 Aug 2004 11:10:22 -0400 (EDT) Received: from 66.238.227.126.ptr.us.xo.net ([66.238.227.126] helo=ACHAL.westridgenetworks.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C2AJ8-0005XR-JH for mpls@ietf.org; Tue, 31 Aug 2004 11:12:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] Requesting your feedback - issues/errors/clarification s Date: Tue, 31 Aug 2004 11:10:13 -0400 Message-ID: <4CBA3FC94D69F945A50C05DA8EA2C4D01A2BD3@ACHAL.westridgenetworks.com> Thread-Topic: [mpls] Requesting your feedback - issues/errors/clarification s Thread-Index: AcSPTFumATmQ+YUjRImYjXCpaHIj0AAHYPrA From: "Eric Gray" To: "Bob Thomas" , "Arashmid Akhavain" X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 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.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Content-Transfer-Encoding: quoted-printable In addition to Bob's observation, one of the "known bugs" with MPLS/BGP is that the BGP peers MUST know (in some un-specified way) that there is a continuous LSP from peer to peer before they can use the LSP to carry MPLS/BGP labeled packets. In this case, the ingress PE should not have forwarded the packet using the MPLS/BGP label without "knowing" that=20 the LSP was continuous peer to peer. An example technique might rely on the Hop-Count loop detection mechanism, possibly in conjunction with an IGP routing protocol. As Bob points out, if the LSP is incomplete, the LSR where it terminates SHOULD discard the labeled packets it receives. Remembering that the LSR in the example gave the label L10 out for a FEC for Z, that LSR SHOULD be anticipating that it would forward the enclosed packet toward Z. Finding that the underlying packet is not - as expected - an un-labeled packet (it SHOULD expect this, because it does not have a downstream mapping for a FEC corresponding to Z), it SHOULD discard the packet without processing further. This would result in black-holing the packets, rather than mis- directing them - and would actually be because of a misguided MPLS/BGP implementation, rather than an LDP problem. Even if the LSR did do further processing, it is NOT correct for the LSR to=20 assume that it issued the underlying label - since (as Bob points out) it did not issue the original (freshly popped) label (L10) for itself as a destination FEC. Looking further, it would see that it did not receive=20 any such label from the next hop for FEC Z, either, and would then discard the packet. If the LSR pops a label expecting to have terminated an LSP (in other words, not as a result of PHP) associated with an IPv4 FEC, it should expect the underlying packet to be an IPv4 packet and discard it if it is not. We should write specifications to tell people what they need to do the right thing, not to tell them all the wrong things they should not do. > -----Original Message----- > From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Bob Thomas > Sent: Tuesday, August 31, 2004 7:04 AM > To: Arashmid Akhavain > Cc: 'mpls@ietf.org' > Subject: Re: [mpls] Requesting your feedback - issues/errors/clarification s >=20 > > Packet misrouting can happen under the following circumstance. > > Consider the following L3-VPN network > > > > > > A----------B----- ... ------Z > > > > + B sends a label mapping message for loop back address of Z to A using > > the independent control mode of operation. Let's call this label L10. > > > > + Z advertises label L100 for one of its VPN routes to A via MP-BGP. > > > > + B could also be a PE and could have allocated label value L100 > > to one of its links to a CE device it is connecting to. > > > > + Receiving L10 for the loop back address of Z, A will be under the > > impression > > that it has a full path to Z. > > > > + A starts transmitting packets with outer label L10 and inner label L100. > > Meanwhile > > no label representing the loop back address of Z has arrived at B. > > > > + B receives the labeled packet and pops L10. > > > > + B then proceeds with the processing of L100. > > > > + B recognizes L100 as a local label and transmits the un labeled packet to > > the > > wrong CE device. >=20 > This behavior of B appears to be in violation of the spirit (if not the > letter) of the advice in Section 3.22 (Lack of Outgoing Label) of rfc3031. >=20 > Unless label L10 refers to B itself (which it doesn't in the scenario > described above), forwarding the packet according to the label beneath > it (L100) is a forwarding error. >=20 > Bob >=20 >=20 >=20 >=20 > > Arashmid > > > > > > -----Original Message----- > > From: Bob Thomas [mailto:rhthomas@cisco.com] > > Sent: Monday, August 30, 2004 12:58 PM > > To: Akhavain, Arashmid [CAR:NP62:EXCH] > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Requesting your feedback - issues/errors/clarification s > > > > > > > > > Please see my comments below: > > > > > > > > > + I agree with Luca. I have not seen much use for loop detection in > > > DU mode of operation. So, it would be nice to either clarify its > > > use. > > > > > > + I also agree with removal of the HOST FECs. Although they are > > > + supported > > > by the protocol, I have not seen them being advertised. > > > > > > + I agree that the selection of FECs for which LDP sends label mapping > > > + message > > > should not be a requirements of the protocol spec. The FECs should > > > be either > > > determined by the applications as Ina mentioned, or controlled via > > > policies. > > > > > > + As for the use of DU in conjunction with independent control mode of > > > + operation, > > > I agree with Vach that DU and IC can result in black holes or packet > > > misrouting > > > > How does it result in "misrouting"? > > > > > > > in the network. The scheme works fine for IP forwarding, but as Vach > > > pointed out > > > in his e-mail, it creates issues in VPN networks. > > > > It seems to me that the appropriate place to address this issue is in the > > protocol applicability document (i.e., rfc3037 as opposed to rfc3036). > > > > Bob > > > > > > > Arashmid > > > > > > -----Original Message----- > > > From: Luca Martini [mailto:lmartini@cisco.com > > > ] > > > Sent: Thursday, August 26, 2004 5:19 PM > > > To: Ina Minei > > > Cc: mpls@ietf.org; vach.kompella@alcatel.com > > > Subject: Re: [mpls] Requesting your feedback - > > issues/errors/clarifications > > > > > > > > > Ina, > > > > > > Please note the following points: > > > > > > - the LDP loop detection mechanisms do not make much sense in DU mode. > > > This is the hop count TLV, and the Path Vector TLV. ( When LDP > > > interoperability testing was just starting , I had most vendors out > > > there remove it for DU mode ). 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 ) > > > > > > - The Host FEC is accepted by most implementations I worked with , but > > > sent by none. So I also think it's probably a good idea to remove it. > > > > > > Luca > > > > > > > > > > > > Ina Minei wrote: > > > > > > >>>Issue: do we really have to send all FECs in our database whenever > > > >>>we have an LDP session between two peers? > > > >>> > > > >>> > > > >>This should not be a requirement of the protocol spec, the > > > >>application which is using the protocol should determine which FECS > > > >>get sent. > > > >> > > > >> > > > > > > > > I agree. This is not a specification issue, but rather a > > > best-practice > > > >based on the application for which the protocol is used. If you only > > > >need the loopbacks as FECs for your application, then it is best if you > > > >_ask_ LDP to only redistribute the loopbacks, because it will make your > > > >network easier to troubleshoot. > > > > > > > > Ina > > > > > > > > > > > > > > > > > > > >>>Issue: with all the combinations of Downstream Unsolicited, > > > >>>Downstream on Demand, Ordered Control, Independent Control, etc., > > > >>>it makes sense to define a mandatory combination. DU/OC seems to > > > >>>be the favored one. > > > >>> > > > >>> > > > >>I believe this would put a majority of the deployed LDP speakers > > > >>out of spec. Such a change cannot be made as part of going to DS. >=20 > _______________________________________________ > 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