From mpls-bounces@lists.ietf.org Wed Apr 05 13:25:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRBj1-0001FT-BM; Wed, 05 Apr 2006 13:23:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQ8jv-0000G0-3y for mpls@lists.ietf.org; Sun, 02 Apr 2006 15:59:59 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQ8ju-0006nc-Qq for mpls@lists.ietf.org; Sun, 02 Apr 2006 15:59:59 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k32JxSBX024138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Apr 2006 19:59:28 GMT Received: from mirror by ietf.org with local (Exim 4.43) id 1FQ8jQ-0004AE-IG; Sun, 02 Apr 2006 15:59:28 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: George Swallow , Loa Andersson From: Greg Jones(ITU-T SG 15) Message-Id: Date: Sun, 02 Apr 2006 15:59:28 -0400 X-Spam-Score: 0.6 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-Mailman-Approved-At: Wed, 05 Apr 2006 13:23:21 -0400 Cc: mpls@lists.ietf.org, mark.jones@sprint.com, maeda@ansl.ntt.co.jp, info@mfaforum.org, Ghani.Abbas@marconi.com, sbrim@cisco.com, fenner@research.att.com, statements@ietf.org, rcallon@juniper.net, tsbsg15@itu.int, betts01@nortel.com Subject: [mpls] New Liaison Statement, "T-MPLS Consented Recommendations" 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: , Errors-To: mpls-bounces@lists.ietf.org Title: T-MPLS Consented Recommendations Submission Date: 2006-04-02 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=207 Please reply by 2006-04-17 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG, CC: MFA Forum(George Swallow , Loa Andersson ) Cc: info@mfaforum.org maeda@ansl.ntt.co.jp sjtrowbridge@lucent.com rcallon@juniper.net fenner@research.att.com sob@harvard.edu sbrim@cisco.com mpls@lists.ietf.org Reponse Contact: tsbsg15@itu.int Technical Contact: Ghani.Abbas@marconi.com mark.jones@sprint.com betts01@nortel.com Purpose: For action Body: We apologize for not having sent a liaison regarding three consented Recommendations related to T-MPLS. The intent of these Recommendations is not to change MPLS but rather to identify a subset of existing MPLS necessary and sufficient to provide connection-oriented packet transport. The approach to the work was to make a profile of the MPLS data plane functionalities defined in IETF RFCs using the description of MPLS provided in G.8110 (which was approved last year). The intended application of this profile is to provide a connection-oriented packet transport network. The focus of the three new recommendations is on the data plane aspects of T-MPLS. Control plane aspects are currently for further study and the work on this subject is starting. According to our work methodology the T-MPLS definitions are split into the three main Recommendations that have been consented in February 2006: * G.8110.1 dealing with the T-MPLS Architecture * G.8112 dealing with T-MPLS interface specification * G.8121 dealing with T-MPLS equipment functional specification A brief high-level introduction of the essential features and selected options for Transport MPLS can be found in section 6/G.8110.1. The objective of the work done by ITU-T SG15 was to define a way to use MPLS as a connection- oriented packet-based transport solution for packet aware transport networks that can support both packet and circuit (e.g. SDH, OTH or WDM) switching technologies under a common operation, control and management paradigm. For this purpose T-MPLS deploys the MPLS frame format, Client to MPLS mapping and MPLS to MPLS multiplexing and complements this with transport network OAM (Y.1711), nested connection monitoring requiring the labels to be present up to the final node in the network, protection switching (Y.1720/G.8131), transport network based control and management planes, maintaining frame ordering and a restricted number of classes of service/queues. * MPLS has many applications and it is desirable to identify a subset of MPLS technology that provides the necessary and sufficient functionality for transport applications. We have indicated below some of the options we have selected :- * In IETF RFCs the usage of PHP is optional. We decided not to use it in order to simplify OAM procedures * In IETF RFCs the usage of merging is optional. We decided not to use it in order to simplify OAM procedures and also because the relative lower number of LSPs to be supported is not considered a major scaling issue * The usage of ECMP is optional. We decided not to use it in order to simplify OAM procedures * Leaving labels 16-31 for further study was seen as a no change because the label allocation on a link is defined in IETF RFCs as a local matter for any MPLS device. We are not expecting that the current version of the specification is going to create any interoperability issue. We envisage two possible cases of interoperability: 1. Interoperability between a T-MPLS box and an existing full-featured and fully configurable MPLS box can be solved by configuring the MPLS box to use the same options selected by T- MPLS (T-MPLS being a profile of MPLS this should be possible). In this case the link between the two boxes is a T-MPLS link and in the scope of our Recommendations. 2. Interoperability between a transport platform supporting T-MPLS and an existing MPLS box that uses a different option selection than T-MPLS, should be solved by the transport platform. In this case the link between the transport platform and the MPLS box is not a T-MPLS link and therefore it is outside the scope of T-MPLS recommendations. We are looking for cooperation with IETF to develop the detailed specification of this case. Please find attached the text of the consented Recommendations. Please note that some minor modifications may be made to these draft Recommendations as a result of comments made during the approval process We will appreciate your comments and suggestions in relation to the initial scope of T-MPLS as a packet transport network technology. We are planning to review your comments during the next meeting that is planned in Kobe (Japan) on 22-27 April 2006. Results of the comments will be included into our future work (e.g. corrigenda or amendments) on T-MPLS Recommendations. Amendments of T-MPLS Recommendations are already in our plan for the next SG15 plenary meeting in November 2006.We are looking forward for future cooperation with you in T-MPLS data plane and control plane evolution. Attachments: Consented Text of G.8110.1, G.8112, G.8121 Attachment(s): Consented Text of G.8110.1 (https://datatracker.ietf.org/documents/LIAISON/file288.zip) Consented Text of G.8112 (https://datatracker.ietf.org/documents/LIAISON/file289.zip) Consented Text of G.8121 (https://datatracker.ietf.org/documents/LIAISON/file290.zip) _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Apr 05 15:53:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRE1m-000190-KY; Wed, 05 Apr 2006 15:50:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRE0x-0007u0-Cu; Wed, 05 Apr 2006 15:50:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRE0w-0007N5-NS; Wed, 05 Apr 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k35Jo10e024622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Apr 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FRE0v-0003tc-Rx; Wed, 05 Apr 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 05 Apr 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: mpls@lists.ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-ldp-upstream-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: , Errors-To: mpls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Upstream Label Assignment for LDP Author(s) : R. Aggarwal, J. Le Roux Filename : draft-ietf-mpls-ldp-upstream-00.txt Pages : 9 Date : 2006-4-5 This document describes procedures for distributing upstream-assigned labels for Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch LSR traffic replication on a LAN for LDP point-to-multipoint (P2MP)LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-upstream-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ldp-upstream-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ldp-upstream-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-5130133.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-upstream-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-upstream-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-5130133.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Wed Apr 05 17:24:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFST-00075H-P8; Wed, 05 Apr 2006 17:22:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFSS-00075C-FL for mpls@ietf.org; Wed, 05 Apr 2006 17:22:32 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRFSP-0005sa-4p for mpls@ietf.org; Wed, 05 Apr 2006 17:22:32 -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 k35LMSX41734; Wed, 5 Apr 2006 14:22:28 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k35LMN590927; Wed, 5 Apr 2006 14:22:23 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id k35LMM7v050754; Wed, 5 Apr 2006 14:22:22 -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 k35LMId1050751; Wed, 5 Apr 2006 14:22:22 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 5 Apr 2006 14:22:17 -0700 (PDT) From: Kireeti Kompella To: xuxiaohu 41208 Subject: Re: [mpls] Comment is expected on draft-xu-mpls-rsvp-te-bidirection-00 In-Reply-To: <1365d4f13673f4.13673f41365d4f@huawei.com> Message-ID: <20060405141733.Q50736@kummer.juniper.net> References: <1365d4f13673f4.13673f41365d4f@huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org On Thu, 23 Mar 2006, xuxiaohu 41208 wrote: > Is it worthwhile to achieve bidirectional TE tunnel with little > extension to RSVP-TE? Any comment is expected. No. We already have a way to set up bidirectional tunnels. But that is not the main reason for my objection. The main reason is that the further that MPLS and GMPLS diverge (and the more diverse ways there are of achieving a particular functionality) the worse the MPLS-GMPLS interworking/migration problem gets. Pursuing this work would have a detrimental effect on MPLS/GMPLS. Kireeti. ------- _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From clyqesbo@bayareaamusements.com Fri Apr 07 06:36:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRoKe-0003sZ-Hc for mpls-archive@lists.ietf.org; Fri, 07 Apr 2006 06:36:48 -0400 Received: from [80.74.161.166] (helo=mx2.hostasaurus.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRoKZ-0007Tf-P6 for mpls-archive@lists.ietf.org; Fri, 07 Apr 2006 06:36:48 -0400 message-id: <008001c65a2f$240e0860$3b5a2ded@ZRHTVV> From: "Rob" To: Subject: The obvious choice. Date: Fri, 07 Apr 2006 05:36:34 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1830 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 X-Antivirus: avast! (VPS 0614-3, 07.04.2006), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Obtaining a DIPLOMA has never been so easy ! Call today and find out how you could get your DIPLOMA from a highly credible college, Full Transcripts, A Letter of Recommendations, and even honors. 1-206-984-0106 No required tests, classes, books, or interviews. Diplomas are available include but are not limited to: Bachelors, Masters, MBA, and Doctorate (PhD) Available in any field of your choice. Everyone is approved, Never is anyone turned down. Total Confidentiality assured. Call Today 1-206-984-0106 get a DIPLOMA within days!!! 24 hours a day, 7 days a week including Sunday and Holidays. 1-206-984-0106 From mpls-bounces@lists.ietf.org Sat Apr 08 16:13:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSJlh-0008QU-Vy; Sat, 08 Apr 2006 16:10:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSJlg-0008Pq-Jz for mpls@ietf.org; Sat, 08 Apr 2006 16:10:48 -0400 Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSJlf-0000Rw-7y for mpls@ietf.org; Sat, 08 Apr 2006 16:10:48 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id NAA04260; Sat, 8 Apr 2006 13:10:41 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 9 Apr 2006 01:40:40 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: One LDP Implementation specific question of receive label mapping for prefix FECs Thread-Index: AcZbR1+SBsJJsOnuQLCI23Y0E3362g== From: "Dutta, Pranjal" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Subject: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs 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="===============0205503720==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0205503720== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65B48.8201C5EF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65B48.8201C5EF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have a basic confusion on the "Label Mapping Receive Procedure" explained in the appendix of RFC 3036. One step says "Find the FEC next hop". When Ru receives a label mapping for a FEC of type IPv4/v6 prefix from Rd, the next hop for the FEC can be determined after route lookup. Now here, for looking up the FEC at Ru do we need to do exact match or Longest prefix match? It is quite possible that the prefix as FEC mapped by Rd may be within a supernetted prefix at Ru. The reason why I am asking is I guess the implications could be different based on whether LSR is merge capable or non-merge capable. =20 Thanks in advance, Pranjal =20 ------_=_NextPart_001_01C65B48.8201C5EF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

         =       I have a basic confusion on the “Label Mapping Receive = Procedure” explained in the appendix of RFC 3036. One step says “Find the FEC = next hop”. When Ru receives a label mapping for a FEC of type IPv4/v6 = prefix from Rd, the next hop for the FEC can be determined after route lookup. = Now here, for looking up the FEC at Ru do we need to do exact match or = Longest prefix match? It is quite possible that the prefix as FEC mapped by Rd = may be within a supernetted  prefix at Ru. The reason why I am asking is I = guess the implications could be different based on whether LSR is merge = capable or non-merge capable.

 

Thanks in advance,

Pranjal

 

------_=_NextPart_001_01C65B48.8201C5EF-- --===============0205503720== 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 --===============0205503720==-- From wijzwofeon@activeware.com Sun Apr 09 05:53:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSWbk-0001lR-Rw for mpls-archive@lists.ietf.org; Sun, 09 Apr 2006 05:53:24 -0400 Received: from host-81-190-23-227.torun.mm.pl ([81.190.23.227] helo=toru-1cf04d661d.torun.mm.pl) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FSWbi-0005Tp-Ru for mpls-archive@lists.ietf.org; Sun, 09 Apr 2006 05:53:24 -0400 Message-ID: <000801c65bbb$6fdb1ac0$e317be51@toru1cf04d661d> From: "wijzwofeon" To: mpls-archive@lists.ietf.org Subject: Fw: mpls-archive Date: Sun, 9 Apr 2006 11:53:22 -0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C65BCC.3363EAC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 ------=_NextPart_000_0004_01C65BCC.3363EAC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C65BCC.3363EAC0" ------=_NextPart_001_0005_01C65BCC.3363EAC0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Head Bernard=20 To: bgmekjftsn@4x4-edouin.com=20 Sent: Saturday, April 08, 2006 10:54 AM Subject: mpls-archive ------=_NextPart_001_0005_01C65BCC.3363EAC0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----=20
From: Head Bernard=20
Sent: Saturday, April 08, 2006 10:54 AM
Subject: mpls-archive

 
3D""
------=_NextPart_001_0005_01C65BCC.3363EAC0-- ------=_NextPart_000_0004_01C65BCC.3363EAC0 Content-Type: image/gif; name="mpls-archive.gif" Content-Transfer-Encoding: base64 Content-ID: <000301c65bbb$6fdb1ac0$e317be51@toru1cf04d661d> R0lGODdhFwL0AYcAAP///wCAAAgAAAAA//8AAPbu7qFERMyZmYAAAMOIiOXMzBc9M927u7t3 d/q/uNgxreWIbQbpGxG4kogREZAiIpkzM+7d3ZKAct00c9SqqqpVVZ8hHbJmZsFOz3kBCAAz ZgZTB0VQW01RK+wY0DsDpNEOtT7k3uMxCqI2IGKXq2V2cDnh2Vl5mirvLKhojtRZxP21BdRR w8f/X8ZBQ64Hw+88y41/HY+kDN62yShG8HdbTaWtXbm7EcO1DiPvO+oHF18NxVkEBWcJIYZU C0XjYuo1803IugTNmBzp8Xck6fF39P///wAAAAAAAAAAAAAAAAAAAAAAAQDMAAAAAVQAYQBo AG8AbQBhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA5PruAMwAAAAAAAAA4wEAAOT67gCZAQAAmQEAALT67gB28NN35gMBfygAAADj AQAApPruAAAAAADIBZF8mE3mAHD77gBRBZF82AcHAG0FkXz+////FQAAAAAAAAAAAAAAYPvu AAvw03fmAwF/AAAAAAUAAAD+////FQAAAAAAAACZAQAA4wEAACADAABYAgAAKAAAAAEAAAAB AAAADgAAAIcBAAB7AAAAAAAAADgAAAAAAAAAAAAAAMwAAAAAAAAA4wEAACADAABYAgAAGO6Q fAAAAAAAAAcAAAAAAAAAAADKTeYAFQAAAAAAAAABAAEABwAAALT67gDKTeYAZHYACAAAAABw BZF8/////20FkXykx9V3AAAHAAAAAACgTeYAoC8wAnb87gCU/O4A4wQAAKBN5gDM++4ACMfV d+YDAX+gLzACLIcAAPz77gDvsvN3vPvuAPiy83f0////AAAAAAAAAAAAAAAAAAAAAAABAMwA AAABVGFob21hAADiNxkBdvzuAKAvMALAiBkByIgZAXb87gAshwAAuLXxd4a18XfmAwF/QQEA AFYAAADUWcQAdvzuAAwAAAAAAAAA1FnEACwAAAAAFwL0AQcI/gABCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtKnTp1CjSp14YqrVq1izat3KtavXr2DDih1LtqzZs2jTql3Ltq3b t3Djyo2KAAHCunftKqyLVyBfBgX5CqzwdyADvhX88l3cV6AFDhTqUuBQYCDjy3oFFoAsuYFB zAgMZGCogDFggovzgraMWTRr0I3zyj4Ye65tnwUOGDDAQAHB3Lt7/9bN27fqzHwnBO57gK9n gQ34HlC82vGEyxMsUIc90MJ1xtlR/sMerZADYw7La7/GvP4yediCEQIvPjy4cc3Ehd/ev9PA YgME+ccXgAMJWBeBtMUHwH/i6VUAYgMRVldlC3I3GGgabFcdAN9dRkGDmH2oUIcKbnfcZe0x JiJ86hXIoIsDBvgifzTe1BwCB1A40I05FsSjjp8pyNh01EUoZF2JmXgcABYkF6R6CUAIgIQ4 rudYagllgBl5Sj6ZmZdXltjlQj/6WFePBJVZ45o07babQW4iWKCbex2JQGThVZjZjQgAdtiZ ViLUYQZAglmQgcaVdmCgiiKgXEJURoYkiEtW2uijlDYUJ5x0Htopm6DClIACBTxH0KilGoSq qQk2xpei/0kq+GBdnkU3YYolRrkYBaxm6queyMGGnnyLzXrrmCAylux5hjK0qqqk9grAs6FW +xSWek5bVwLZGolAYhLKaeFACZDoqHbpfTkmtrAliZCtCGRoHq2BeqksrpM2a+2+cbHbl4RN xqblhHxxCey9BTHQgKSh6buunYxVUGhBDAPWqIjAnojtwYhNnDG/IL/lr17e3SkmX/Oqu/FC K39MEJWJxmgivHImzOJpLSNLKc2tqhvyz2eNvCPCAmnAWIa/pmtBwOq1rOu3FwKqJMMGE5Qy hjpnPXXBDgPt9VhCw1jbwFwvi63RmA2btEDmOhlocyHcqTF7HEOMopJ8Ylzv1/58hxW2Zh3a ay/CJYM3cc6FLzbBfS4PahCf7grE8HTjwlev42v3rblWfwv0p89oxzv4xo9JOpnHOQOwmemU pUuuzC+XPRDZiVVue2NP15z65rz37vvvwAcv/PDEF2/88cgnr/zyzDfv/PPQRy/99NRXb/31 2Gev/fbcd+/99+CHL/745Jdv/vnop6/++uy37/778Mcv//z012///fjnr//+/Pfv//8ADKAA B0jAAhrwgAhMoAIXyMAGOvCBEIygBCdIwQpa8IIYzKAGN8jBDnrwgzDJAQhHSMISmvCEKBxJ AAJgkRWWxIUVgSFRZPhCFqbQKSvMoQ1pKBAeJsSHC/7RIRAPMkSHFBEhR2SIDjECQyHu0IY9 ZKETBzJFIUbxhk2RoQuTGEQoQoSLBAHjD71oEjF28YpXpOEWoahGNpLRjFjsiRalSMcnAmCN blziHXOYRiJ6UY97XGMg0zhHPu4xioYMJB+bmMhEItGOjXRkQeZIRTqG0ZKVzCQaLxlHpVDS kIIEJSYPyUhF+lGTgqwkJEv5yVGmkpSYTCUZJ/nEVSrRjZls4yE1ucte8rKTRmllLl1JzF2+ 0iCUhCUnCTnMZgqTmayc5Sl7ecxH8hKPVtTlJq24SWAWZYrUtOQzYbnEIhZykX/E5ThDqc52 KpKR0lzmOMeoSlFyUpvhRP9mPL35Ex8Kc52j7CYtf+lLgObzlQgVZzyPWEpmnlGgBQ1oMn0J UX4CxZ/ufCY6qUjRZVIzos10qDI1yk6O2rGjDVWmR7c5S11ONJ8DtegMW5pRXA4SniedJiLz WMxkchOneVQpICNJy4TuFKIp/SU2efjSjsoUfHCsqEaimhGqPvV53IzIPqe6VY9Y9apgDatY x0rWspr1rGhNq1zaONSsXlKPLs1qFQG5U6DSFI3gbCVdr6nUdML1ryul6F9FuVc11jWnNv2q Wv040ZRiNKQixSdDbSrQaN7TnUitJUuZStk7gjSwxvwjQRFp0nSG9qSKXWxRO3tMzkJWpSwd rUf+8YlXifa0s7VFrCRfatuYylO0FW0kSOFZW9UyEbWmpe1Bk2va2NKzmxhNqlGbakzPhha6 uP3saJMKWs82cbg7tC53jSuRhsY1sHrNZnPDKUnnZla6t91rPU1Z3GvSFJzb5el6w9hHbZaT qOSNIXIvCwGC5pW5s81ugrvL29s69ahtxW5+0XtXfcoWkp/9L3UDbEQn9la5j31tY7faYJ2e 16FD1HAt5cpa7Wa2hwtGpiozjM7U4uQFDDzxdV/sW9hKlsSslWaJDWriINuXvyCu8HqBGNQf 95XDE4lrW+WLUuYWVsF9pXJEpwzfIj8Zu/Y0sHqByuDf0rXEEPwBlNf+zOY2G0UCbo6znOdM 5zrbeXs2XlOeH9LVIN75udZ9sKAnC9hhcnmpPZYqRfD70O7yuc+PbK8/e+xWGNe1nvp9K6Q7 SdxB73OyIi7mkRn71o0oN9KlFnCUg/xGTY/a0oH2saj3TMJOF/LSpsSjhUUKW5g+eLArHjB9 V8rO+64Y17o+7Ix3/OqAxtq9hj2lQWkNvR5E5buore+WK4tZXo8Yie+U9XW5K+XKhnu6lsUr it+YWHP7lrfWnHalw6riXaNZsO2ca4zDzd9BijvdroUsU0n77267ltzqVKqXt2nN5Qp803Gs N7KNzO1Ce5uyKeZoZI/9TnZf1sAaL/jDJx7/YnIOdeEf3bXDN15WiZuX4vhWea+/TURpJzbM OhV3vwcq75DiVOUBf3azwyvznitapjR37JI9TmlRu3eSNh96yCXcVCE7eN2xVHDV2dhwmFb4 yEQma4MjeeytF72Ou8Wy1XENZqtbfOD2frtmySzVeWtRn8DmuqYJe85M/5l6eYZ4zf9+v8C3 kPCIT7ziFw8yFDD+8ZCPPPSCIPnKW/7yZCEB5jfP+c57/vOg998MQk/60pv+9KhPvepXz/rW u/71sI+9WgVAe9rfxPYDEYBLPsD73guE9wQBfu8/AADgD4T4wzd+8ZO//OEfJPnIZ37zja/8 5Vv/+L+XfvWz73zu/lPf99D3PvET4vzqj1/6JcS9QHRfk9rnfvfjt775z0//+Ef/+PQviPK3 j//+l6D/2Dd/zReA8Sd/BXh92YeAxZeACqiAB6h/9UeAwWdC6gcA7Fd7uIeBuud+FriBFciB tgeCF8h+uad+JCiC7seBHWiCJOgQ+3d/APh99ueAMAiADWiD22d+NDiAv7eDOViAwgeEDPiD E0h+EdiDOrg9PnAUFbh+J+iBThiFIrh+UpiBUNiBBXGFF1iFUYiFVtiFD/GCO3h9MFiDBgiB NoiGDJiGayh/ZOiDByiA/EeGcfiARoiE53eD6deCYBiCI8iFYAiIXviHBPGHfOiHXYiI/1hI EWIIfd/Xg24oh8wXfgjxguX3gI6IfAlohkGohpt4hDLoe9Nnh8GXh5FIiiPUhIs4iIl4hYuo gatohapoiE6YgoTohxhYEZQogG94iqXYgJ14h214g3K4iXDoiWc4hPknjJVoisKnhyT0gbGo hYb4hK/oirLIhxZYgtR4jYJoEfzHi9SHf5xohnTIjEQogf1nf8H4icjYjo8IjL8ojOzIiRTY gtjYjawIiIo4jQfxhN34hfu4javogpgIhMtYjwgYjzhIimI4j3j4iwopie9Yg/GYg/MYjqY4 gEk4hxoEi7UokF+ogQDZjyz4j4U4grbYiiFZghGhkRIJfjHZff+jWI7PV4+iqH0IuYAxqJPd R4k1OX1BOYpsWH4ZSZMeCVaqCBFLCUBJeWdN6RBR6T+oKHtWeZVYmZXiAwRaKXlTmRFf6ZJd GSogWZANMZVlGRFhGYgvqZMzKYpBiX7kmJNyOZYnIY1myRBRiZdqqY0IsZbNuI47+ZBr6JEU OYx2SRLSCJJlmYsCKZZUOJKOKZkleYt+qRCNOJg7WZgOqZlsmJgjsZQn+Y39CJliqYiUCYgd gJqXiY42yYsL2Zkx+ZmgKRKNaY2kqYJZmIveKJL56I+AeZOCGX6waYnp+Ik0WZsp8Zgn+YFr mY0sOZAm6YoSsYue2ZC0eYyIORMrkHr/+EiIwPmdopmSLemN0vmbwWkQMCmYEEmYFRmbylkS 39mH1uiceTmf9MmSzVmf4GmQ6nmdYwiMr8mO8SmfvFmLIVmS5pmSujmalKmCjNmfDbGeyAmX nKmG1pmcBQoV6bmh5dOhHhqiIjqiJFqiJrpBIJoQKaoRBHCiX5GWbJmXUsmbK5oRLUoQBJCj OXoQOrqjAtGjNwoAQBqkLioTHZqii9maIgGkPxqkPjoQRLqjUXqjT1qk7Tef1HigU2iWSZqg 3MiNuPkQUvqjQuqkRGoQVdqkamqlNuGciOig/HiI2jidr2ieHTqmUGqmCpGmZdqkOsqmMwGL +2ma+9iEs4ie//hZo2X6pIx6pn46pXzap4AKE/YpiNmoknOaqf64ggmqpA3Ro2sqqQjBp6Tq qJOqEpV6nnaqm4EIhaP5jRjRolKqpwlRqmhqqqeKEqnKmvooo13anJYaowtBpX3aqGo6pUKK o7KqrLnqEruqktcIoZcZoV6KoOUpo8MKqo9Kq0y6rXn6p826FIqaErgarmsxrihRrua6ruza ru76rvBqFOgar9ZCkjOaFBlKl/q6r09JrxwBovP6EsVJoOqYjNDor/8qp634pm5ahZWJqYTK EQObhhZZsQgbmgo7kJxap4NYjS7pmyExsYiZmdl5sRphryvYn69qqYgqrB4hssTok/8WarIe IZphuqmCyp8fC6MgAbMUCo9VSbMWcaiPGZ4sa7Qo4bNCSLLbKbQYYageC5msibQrSYXYmhFK O4FMe7BOWxH26pt0mrK/yanQ6bIaAZQ0yK/1N7NdmxQB27Yhw7NwO7d0W7d2e7d4m7cRBAJ6 27d++7eAG7iCO7hOgQGEe7iIm7iKu7iM27iO+7iQG7kaMQADILlpQbmYW7kUQbkFwbmbq7kC AboX4bmWWxKkS7oRgboYgbkDIboWobqlGxKnW7mcq7mZSxCsCwCeW7u027ugm7mqm7u6G7q5 u7u2e7y/67qxCxKzq7usa7yhS7zOO73TW7y927que73DC73/0Fu9tiu9yzsSwHu82Au+5Xu7 0tu8zYu76Uu93Ku9wau84dsR6pu86Au8ziu6vHu+ydu57Tu+6au9+Vu+8yu7/bu+BMy79cu/ BNy62CvAD4y/uCu/BewRC2y+8Hu978vAA8y+xCvA/Uu9w+u+FFzBqyvBqIu++bu/3ivCxgvB Iwy+KkzCExzCJvwUsHvDQDG+PNzDPvzDQBzEQjzEM6zDRnzESJzE36MCStzEYeGphSgTIvAS G/h+TKmWNfuvTAHFdykXt6mgDCq1YvulC/GcBFmtUUyj0mrFJ/sQgqoQcjqeJ1jGIJiFZSyV bqzFbLwTVWzHRmob+GjFc2y1BGmC/3s8yCrKxYTsx2n8foNsyCuhyIvsqX18xn/pyFjcEZJ8 llH8E3MaqIC8x9v4yHbcx4h8iCpqtTQ6ypYsyoWMyar8yhu7hYUcgrFcxdDKyJFZyx5YyWHM yq2MkpFZx1qKgrssyG5Ky9IKkNaasr/MqrOMgsx8xr08zazayww6zRtLxs5syiwIxl4sypVM y5hMzoi8yH5sznXql59Mze4MzOMsy76szKOsztmMy+T8zpdsynoJy6w8xwDtyKjMzuUszpYc 0JPMxtPqzggNzA49z4cczOfs0Pss0IQczxP9FhNdzQa9haesy+l80QxtEATtzCb9ytWMy/8c 0CpdmWRbyv9ijM4tyc+/XJ4s7c8pLdH3Wc5qPJ0pGNEinc0jfcwPPdRoTNFBPZn/+NNEnbNM HcxusdGy3Mr8/NGdTNJv3NQ6TdLobM8q3cjj3NL/7ModvZv6rNDw3M9X/dVFjcqMzJdsHdRe +NZrDdRtjdNGDdEo2c5F3ap4LdV1PReBHMtybc7nbNUR3dC+DNVTndQfK8gG/c7x3NUwXdmU vcv5fMl1jdF/zdV2zdaTrdWHjdZordh5bdRnvdin/dmrfdcyHdW7OdrNHKZxfNUJvcpE/dqA 3dS5LNmQjNI1XdazDcaOidSaXdq+LYsyjc1Czctgus3LnLHQXNxaDd1PncvX7Nf/qmyLmQqd 4snNByo9ULzJqZwW5N0S590RLvCi6sPF6e3ZaPHeqMo70OzE9n3f+G3enswS00reGeus8q3J fH0WTRngZmHgeJzRkczJMX3Fr23bZK3WD97G4x3hDk4RC+2lEcrO38zNfxngCp7HdG0bDgDf imnhusrgfSgRIU7W6T3YtinhlLrUhkrVke3ajG22Kn4RfI3gViHNsW2t+JyPg+3RZDvdNd7b 3K3N3D3ci7nd9Gzj1pzWXwrQ0f3MGUjV38zZ1x3GHC3ky1zPWx7k22zcmb3bnD3hZx7mK+3N EEvmDYqL2vzEeE3a9UzYqi3Pfc3YierPpw3jpg3LaX7m/1OthTYu0oFe2Fza2Zht560t2o1c 3YjO1e2M24eO461J6KKtzomO2ore4lrR6S5NyncO02It19dKzUqN6NR90a1e5GJuy3H96RH7 0aKO3LFty5AeyG7d169+0I/e0MFN0Gj+6CG92XWO6cg+4rHu40hx65et534t1oid2i6e5qwd 2Lcs5WaO60ht68muz6rd61we6d6O7RAN7cYt6eZO7sYOpnDd2ui+7Nqe52Ch7oGez+6+54Be 7+2O2uCe0FII2bp97gL/59ne7ZDe6BCO8Av/8P2+0Ppe55xO8boc8ck+795u56H9xFne1dhN 8Mwd2LQI8nwZzW9u3ZYJzqo+2/8u/swcL9SP3KAwj9XEzdS/bfDdjMygneqzbPMb3eGuzuQ5 D+zPLeTkGfImr9uTXd/p4+xdkQKZLOP8PREgLp8WBfWwvePLuaLyrfVwnN9ir7gPMPYvCvZ4 zOI8ocj/fcdPe9wX3n5wr8eKifZTX68onvZ6H/c4wfYNH/ZvL8x3r8lDq+2EX945zvVV7/aC jd5Wv/Z7v8k+nuGDT/eP7+iWb+KFP+OM78WyzubFPOQsH/oeTvpgTrRkPOTTaOTKPOapn+Xi aeQoz/ImXcdQfvu179M2DbUpH95L7uFHnvpUbsxfftKn39w/39irrORdfuS9fa7hjuPKjvl5 btr4Xsr/UT7Qsn/9w0zXsxjsjH7X1r/tD7/X4R7wRk/osD/pEE/vBh/lrM7+0g/qBE7xXc7r 58/z1MnqS97xG970AAEAgACBAgwSJFgw4cCDCAUOfAix4EOHESVCXMjQ4MWKFzlq3IhR4UGR ExdWTIiw4ceMFEme/EhRpsmVM1OO7BgSZE6WMyeatMhypcOOPX+WRFr0ZMugTZ0+hRpV6lSq VWFelYk169ajRjlm1OrzKFiLYW8mNdoSps+wbGOiXTvWI9C5PLXeVMs1otm3b4vu/WmXa166 aN0ybStSqV6+bdUyrRpZ8mTKkhsz9ii4K1+xlwuT/RwTL2a4nQ8H5Vx6M2m//qpLjg6NGHPc 1rTPapaIWzfgwqcDi/XqGenc3JWNH0dOmfNQmxt5guSd+6VOnC6Xnq2rk/lv6c4PayfZOSTi 8GBfNqcOXWP09d2rF3cv+rH3wOFdyid8+7xc+97X1rSuK7na60s9865LqbzxVKItOQcfhDBC qSCTsEILL8QQOQoz5LBD9jrc0EMRRyRRw/RKRDFFFaMKcUUXp7JPxBZfpLFGG2/EMUcdd+Sx Rx9/BDJIIYckskgjj0QySSVJZGFJJ5+EMkoYI5wRtQmldLJKqrR0kUsshQTvRtm2pPLKBt2a UkM1L/xrMi+dCnHGM3V888sfw7Sxzg/XvFJAND3U/nNPCQMFTjmo5CyUTjujJCo+APtTMEGV AjSQOkn3Km8kStuD1NLfGFQvwEfTYxC7SzWdblJNK51v1elQxcs5WSmtKcZXV2W1rAVbHZW8 U2/t9T3bMhUwUkIXHVSxsgrc7bbgiGuzpwYXC80moOIC7dnZtkUTNtdMowu20f6LTS9r69J2 wMx8W9c3b/NKLd1l50S2RGeh+28/jLaLVd82VY2OqFpv3amvRhtVtzYADUNpKGw/3W641cKl WFnuSsXtXEntWvjhPzFm765qI/Z2wH/9rfdFZ4XLGL6/EvsqYImxfdm0g1v7mLiR4dNVtN68 Ave1ihF2Gd2fixZu2YQf/qYwW5TK3Zmw4qR+LmUV4eXWtae1hjbkreLdTWbD2pW3ao935npM /j5lm9y0rZw6a6eDBlvmleUu9Gx2j7Waz/ro625jVy8erznAYjQQV4evs47q+ph9DnGzMT2V oaI5NZzywePmnD79TFWIt88FJ/C+0kPP19fN+0UQZ8qzfb3AvpPk27jaZ8d90Tq1vD33IBEn sXffh8/STTKJRz555Zdnvnnnn4c+eumnp75666/HPs2mNsi+++Vp8H5FRI/+MzLYKxOexhHC Z7/9GqWG2/Zk3ae/fulLFdU/wEH9tdPVakVP/n6lM/sV0ICMAlpqmgWcxbCMbFdJ3wElOMEu /gllb3hLXQOttTGAMY2CHwShkcwWtrdBLWp+spwHQ7hCFvKoalwz4QJZo7fJna+FN8ShjISy FOkIq2Ggw9fhyhcp0xELhTlEYhKVuEQmNtGJT4RiFKU4RSpW0YpXxGIWtbhFLnYxhDHwYhjF OEYyltGMZ0RjGtW4Rja20Y1vhGMc5ThHOtbRjnfEYx71uEc+9tGPfwRkIAU5SEIW0pCHRGQi DVgDRTbSkY+EZCQlqT037e4pvdPTmyJoOTaRjYoAzMqsaAKeVPlKVp1qIM3OJLlUFSxU69FO 4wSFIfiZD32XfJAN4WQZSrKIQ9Q6Xgsd8zi0lc+YRqPJuXimrjHV/1J0bstRoKSJSwfpsima nB8tPTnFYXZuXY6LnzPJ8jSsMVBn2DmiNzdUOVwJy1GDIeLMdiW6v70ndoqbpz05RUpWMS4+ QSSQrfL5slNyEnMHAuJ5guWqfJ5OeRAEJTkPZ0TItA5aDUFYzc4XLdI5VFwElFj8LPisZjmu mTFUGrrmZht2kfRr24KZwlJ6uZdecJxZeyBIkwfKi11LiPcM50z/59OfFuudIM0PUa9pUKCm 66MQBVxLfQoyiOKngyQLWMRcqlTBYJSpzLyoxqoDTI7NxmGmK9iJlge/exFtZkeclkglWk6j ggadQr3bOtFqsBkCxQQtU9u/lAXOC6Iupf5z8xpKF1hRxIbUsJyz2NrGQjSO8pCxz2Mrd1Ko zIQdM7M89JnYQqtXeoaOgLBjabVqg1PJHra1JrUZa1Zr05qWJrVg1evdlFo2GA51YpsU4Uz5 d59eRTWwxf0mWlG5qbGe0rm6yolFR4kagRaOuRncHHRRqEp92nNxm1oYJ/23HOsut39sta7m LscchMoyU6ljqD/7M0kfAfeD9qVvE/FrQODl17//BXCABTxgAuNwvzqsUJWcSaQWLWhEChZf 9mp3YPFpFUy1zaVQjVpNXiYnTp7tJVJD7MsMU1OnJEax/Drpty/Rq74a5nCfEmUoFH04nVYR KYxzHLxDxTjFt/5c8XEoXEHvniiewPJf4ia2r5sNzJ/MVfLi3qVd+B5ZlOzcJylbBUvPdZl0 1V3drjpqrHrmj1ZCyzKTpQurjA5UywZraLj4yWbVhSq8WFKhJ0U2NpTS9qbkS2xkuxq0BLpr t0utm2o1aMKcyfBtFdVsMtFcQj3vVdG8XRoQzUUvEtqJaR2zG9v+FjlkDnrUAGsqVjxD0J/G Eidbc2vswIbV3lDVXJNVKFYdyFHC7Q9BjjbPEP1F65otrXGCa+xYZdtiqdINaXh7a7k0jSnR Sotbla31C58N6T5vuNCwdW1RX+tSbk95z7T10/4K261SOzvUQ4S27tadU932NrDWTv92vmvb 6XAXdc+xHvdta+hvoOF2q49eKmRJvetETe7SegNrozft7Hgx22RGHijE3gxxHw7WyqZ8t67z 5il8rk7O84kcKzV9qQESs4jlFfPFQcfOtqJsuobFLniVoiB8urpnpzuQLGHJQJvfuX2WvLCJ e1y/IdsLUDeuI9Lrq9ZZ6rh7TQcU1SE03wJ33etfB3vYxQ4lG3BxAb8kMpWwniJgJlHrPral GdXG9mw6Heoe3uaP75TwCHcYx8aT+455XCa669CayFo73/+++Liz8OMJLRyoAviaeAq9qjEf HJYrn7jKlVLnw4UvlUV50HtW2c5zVnlPF/rDiboZnEf+Z3z+tZsryiqNotltJ63muXv5Ourt QFopBu+q0plTfDCKHX7BR9rNbzkQXHd1a9Icfc7jpy35JAz+d7Z764Onl67Tj6uh0VzWnCIp +52j9TPVPUqSq8bcJLt3/LXPH62Si4PU7mkQz9/BHY7eyC+tPa8CLYKjoVA6tphxLVPqNNYD GcrTl7QyruqDtbQSj/5KunGbtM6yt9O6NkbLjncDQZopOMTaGjiZQFULQeJSPoNqvyYbwZ/r tsaKqg9sNnBLrnmxEuiruuz7qGjLuyPZP4lLN6fiK6gxN+47v3X7s+bLme2rt+iTrQAkNBJU ppa5wbHRN5hJwoAzpxxswuEIP8n/6sEF5Kwhgb1MQyeSq7/NsyqkSbInOzPoSkPXezKeG5Yt qzn/AKrvYhjXoy6PCT047MPcwxfUgzLM+cOLQyb1C5n0IsQ0ezaXccTKSzzEA0IgGzurS5lK xLPf65FpykRNtMRQJMVSNMVTRMVUrBdODKa6QzAztLoDY0UL4RsKm0UA4IEhKYIM8RIX27og 4zvh4bYTM58Ji0VM1Du0E0XGo7GlUzG/IzxixLPGezpadMZorDohM8YdRMZrrMZspMZm1KY8 2akk4zKBeTMTHLPUE70zg7XdOz1SybjLiy9BLC2xIr2OQpWeaydKfC4qCyXMy0dLaSgiksc5 Azp//CH8/+k5PJScfopD36s9hyoeRnO+Hks0o9HByONC1aK37ltB2xNJuJgyQgPDYJy4Jduq FiC/e6urSIurYcwYYJMdj6TJmIw3KGmMPNM2WYvC78rD6DrAi2TBfQPJ39tIQcO0UWPB43rA YUG33mILJ5vAbiGY7yCYkrI594qtPouu9VvIW7RGRaNJlMxIuDnCiolK8rA2xZpKdbSVwcrJ JRzAFhSukTvKZWMWCUxB02otapu+IuSzsizBhbs72olCkGy3jEwqGLrJhmtLSrOruxQboqTL QJstDZRMeTG4oenLJXshKew23rpInvxCnZw8SOlDR1Q2plSv0kI2rFTBnOPHwP95rNvjOpPk rjbUHGSLM9Marwp0LzLDPXlsSJpqQ+BxsjADy3TkSt9azUZ0sDv0nuRDTS1asL4Ry09iTZ30 RCjKTsT7TlUkz/I0z/NUIg9Az/Xckm0cS2+kEfwan+I5POqpz2eEq+GJFr3LpHGET8FTOnGc MWjsmidpOxn7HbyjTAH9EMEiHqkb0P8sMQnFTwaVRgTdJQP9wQqBgcKrO0IhrRnbTjZRN8lT zjhDGXTMQ2OTRH30IcbxzYOUPcw7r9pUPWLxvNlDMkNs0Z9pJUNsL/xQs8/LPRxlP3fsx98E KAeMm2nhp8c7uVeqyLUpwKP5NCrFQNVLTItcyn97wTz/g83IFMwT7ECSpMykDMLLZL6QQ77t Y1HbarUx/cFBS7Yl8TnKAjUrVcKmfC8cVNHQDEj/61J+McJhu8qpEtM79By3PBgLK8oWhcLY 2MmslL+bYT+h7Lc0zQz7k0P+e06POyY7NTUO1NMszSgvFKJYE7hzEs3yEysU9Mi9csHdui0t lbbIgisypdUZalX8YyoU7FUajDgu/LOSYdXMxNOatNPIXFWXxEKFg0zNAlSblEoVOkIFatAq PEnQjESG0dbcEjVcrRsydDdoskIZTEFq6UmWMs1Fu9Df2TjgxLjri82Aaz/RIs7Sy7glfQyT G1LbFC8lNVf3cNK2iseP6U4j/7XNnds4jiwzNgwobUVEj8IyiGQ55bqmgozRcfG+T4ombFxW LzqWEeWmPBlPZlQSkr2ekWXPlq0iI3DZmJVZPZKBmT3MZQRHJDpZwCPQDI1QHFlCWIRQ99lP n50SlS1GS0u7AZVFCxU3x4I7nPUapNWxotVL9hnaZASTAYzPcEwwp8UrXvxF7hOTXeKdn4VX lENSSFy9f10u9QIghkxIh31DgYRYAKzHz6tR1Ns8mtPYlOs8dgwvnmoz/XHOfawn2FsoKYXb t3Vc3tM9P0w4jpVbxLSpNFw2KGRMfNvSfflL6RNRXOWzEkrLkOK1z03JwexcOjXKWl3T1r1a xcSgcP/lN7TkKrR1obi8VATUFvZCj/Uj1v7bv7N6tQQyuvUquhQlVDU716/KzJGiQG5tVry9 XaikvwoMwPTr1N5V3v1gHd34sFlV1r2TXrx6zGmTU2AlW858rJYan9INzHr7y8nCV1edwekt X0StXrwUQQ9KDE5LwNkNUxv0Sz9Vypv92Pw13bwkq/SlXtW9NAE2mbBlOCN0ywV9XnZdXQfW X6WcE0D135xMVwnW1W9JJ07VzLQN0ol9w99VDIXEwwfWPCOCRBaWPW9jypxbTuSFvNYTLr4t qOOEW+zlytikzYBqJXnVwzJj3Ij8MuJU2JbrIQuc4M1C4ARFHqodWwPTUAr/dbyd6kQtbrGd 3REqpmKbReM0VmP0jIA1duNWTJb7DCEx5lmL61mtrbHq8UU1keOcNb/x9eNQTWAvfkWUVbyz 9dqreVc6fk/53NAHFdsrVmQ8frA6VjpENmS64xJGTrB/pFj+6b0gNb3FZcMoPlioJWXDlUjW ETo6O8SPC1ggnrZSNkdYRkgoUyghheHGhdF8xdF4LRY6FJWvEWaKtOOzvBcMA13QDaonhN5m njiG21xqFT9tI1cO3tbxU1anKT4htN+PvNXR1NTTgLSYkjf6Eyh89N3LNStKhWZLZV6d2kkS rlasvFcvxS4UPk2oauCVGVzdlSlcA96veMrZXY5F/5xnLP1Uq53G+e0ZZ+7nt7TCpgw1eC42 nx2hzbxmc+bBC4asYX3BaibVb6bfMKzTcfbgDVrQjIbVg7Ma00TVa/3MlFZJKpTWQpvpVh3V aV3KtPDoVYI3LvXMVf3Cy6RmnEa4CA40EDZKoRZPIR1iSAVD83JYiSTE3IQ8zN3DffUyhQZY FWTiyL1RYK7J30zllvucP+zX9lJNJDZOt+betPaujJViyQOomMsXSe6j8Kxku0vkkn1XD1Wk ubMXMp7QTH6i3FSUN2bsxnbsEdGBx5Zs+hpGvbYfTibk9sEB3JWwvNEeyLgABQ3bbzQTzibG StzjT0Ts9UXZ1O7GqGU60f/2z2wl7RHDUHK07PdZ7UD+a5CFbT2m0a6WW4OMR4dEaxq96uAG 0qE7Uib7JzADuoNlvdpMvcV14swT4hM9bjgs5RrOLgY03DVjboL1w+Vu5brFbLRbZnOyzFnS qKbuSDNFVkqrX5zqWHEj6tEVPlSFYC+MqQL8YJXO5mtGanw2wGobcP1M0Wh2Ycss2IWUljzV aG/O3kN1HSYs3kI8wEb7Z7pdwxLtGLaGwKCCznm900et5/mbre8t0IX9Nd+p4J9m3wjc30Nb SyIMZ8eyyxJ3VWbaTzCtzGWa7zgZVV+9cFaL1phpb4RdcR+F5pIGY4+e8FitNdi93RvH1hzn 6SP/L/DEzG+ePpuBo3I4rWl4mzsUVtPO5Str9UDSNG1GSV6CLW6cc2EivescrVgobuGXK9Hb FFjN0+XX5EOKheo9jOoXneHWqdGfe8gUmlcqDRPANW675uqHVevhtMfOPmyVkVqPdZ70nmMP M+xIfvPEHvUxBvXJVnXk2AEcIYJVh/VYl3XcqewDOnUYT5CvbWy6es+jJfXYhePB020Uw2QI 23XFG3a/ZjFh71piD3ZKPk9/9vByMsgvm/OALFJZTgtVPq86q67eE/LkNVHIxe655UfBDeLx WuJ3cu1ShOjBlI13H9efjehdXfIFtuBKq3IxlFQ3Rd0A7sz4nsj1FN9G/wXou9byNVfaJSW3 GN9C4ZVLigtzNxw2uTrwi9pKAQzy+zPWaI/4j8/UbtXpp7VLlF73jW7x9267/hXpWrpnic4x iKNCHYTa8hzYgW9yMlfdM0/dmdzMGiSNMFR4fjdhfb/CPd1319lym//W2NvURXVb3nwc7e52 Zfvlo8qO4Qs92SGztjZlFn70GpZROJOv0Lzv3DajIfj0O970QEp1UuSdW7dtP3r7Wbf7u8f7 vNf7vef7vvf7vwf8wBf8wSf8wjf8w0f8xFf8xWf8xnf8x4f8yJf8yaf8yrd8xheCy//7I9D8 VScAAngI0BeIz48I0g/9z0f90Ud90Td91beI1f43/dYHANKHfdGffdi//dQvfds/fdVffdd3 /doPCuG//dJ/fd4HfuKXfdAn/t13/uKH/qZYftz3fd0/ftqn/tP//dy3/t6HfuW3fezf/uvv fuCvftk3f+5H//Rnfepv/fBvfyWK/fnXfuR/f95nfvy3f/iP/uK//+cHCAAECAAoaLDgQIIG EwpUiJDgwIUQHR58eDAiQ4QVMz6ceHGiQ48WJUYcWbJkxYYoVypkmbLhx5cjYUrc2FKkRZcu bdYkGfLnx500gy4cCvMk0pkylzJt6vQp1KhSp8pEetMnT6U4jQ7FSNFrzJkobVrdCjYnxaxo Q5K9eXZt0bEsdyZ9mf4QaE25aY2OVas369ujQIX25Mvxb0e8XFXG/SoyY12qkidTrmy56UmB Jq8W7mvYr9nQnfdqvOsR8VnPhY/STAsS7N/Hn1v/JNwzsuCwuheP3p1YK863noXWRc3ZtubM sVtqpn35OfTo0u0yvHvb8erE1nV7NS1a7PaijHNfpx0eeHOMGzuijXn1e+TwqotjR7xbNXjf Kjm3X8sx6H/0hUXfeeKpZ1x3ik23IIMNOmWdfPx1tZd92kkYGHGkNbchhu9JqBZrIYrHoWjv zYZbheV9luJs1K02n4LCnaZhYM6deNxWF+V0Y4LZOfgjkAtCCJl3isnVolLo2YecRil1SP6S jy9CBKWOTpYI5XLeRdnWkO5hByJ+E+onZl6DfbiZT12WqSVuI1b35ZBhBjknnZZlyF2MSC62 nJRbkvYke0neN2WgI3rpHpZ4LfnloGQyyWJvURImI5l4KqlofQo2ydiifdb5KahT3Rmpdujp l+V/la5npYVEtcolc9n96RZkXkZoqY+ozpXqb4JKWeCvh22XIp9rCnuorAOahquvoTr7LLTR SjsttdVaey222Wq7LbfdevstuOGKOy655Zp7Lrrpqrsuu+26+y688co7L7312nsvvvnquy+/ /fr7L8ABCzwwwQUbfDDCCSu8MMMNO/wwxBFLPDHFFVt8McYZa/68Mccde/wxyCGLPDLJJZt8 Msopq7wyyy27/DLMMcs8M80123wzzjnrvDPPPfv8M9BBC22vAJcNMEC8SP9btExMN+y0wUpb e3RUAlgNNZBYyyR1SlxvfbTXXj8ltlNkjw1w0VoDoPXVWEPddkptW10Q3HRfHbfcFTld90Fs 86223i8BHp3ZTBW+1OGGh1p44nEbNPh0kJ+NONdUF9R411Rh/tLm8g7udt927x066aWvffrj TL3N9Nt9s216U5I32LlBtF8+me1A2j666KzffXfvdKe+9tyoQ4408paDnbzlADCP/OVgR6+8 88pLXz311y/vfO3dY6809Ld/X7v22v5zzzzn5VtP9fVL1Z023r+LLrz7pbcOO+rC3y946GqP /nr/5ke8ufmOdQNMW/EOqD+63YBy6wMf9qYHPvOpL3zcE9/2zue9DI6vg9BDX0U++MAONm14 rePd6U44vNQZEHHV26D4bmdBCF6whueTGg1tmDwYxhCHOtSgDA9iwRjeMHreOyIRZ4jEwLEQ gAsMYP1WuL/etfCJ9OMf/fyXRccFcIr5WyAK4dfEFW4NiTvEoBlfiMYedq9yQHwjHH9ovSWe 8YI5tKHegPdFMeaPj8b7ohUV50Y7CvGNNPRhGwtZQzcOkpFAdOQjCxk2SaZRkWlEJB5N50cy bnKTApQi/v6gmEU9crGPrquiE8EIO9Dx8X+inJwcFYlJON7xg4RMZCRxeclK6vKWg8Ti3vIW xj1aEW6yo+Uag4jIHC6PfbIk3/YaScnwNZOadmwmHiH5Q0smcZFL1CQgr5jC4EFufydMoAmN 2T90BpNvTXQnIMVYPNApsJXvlF9UcIhNaUrQmTxU5jWjGcTv+XOX3aQkD39ZyiqCMpAGRGU4 ObfNWhoymWLjZyYxqkFrhnCgF+2oLhWaTYR6s4QsxKIqA1lKU5JxpQ5FKRNjKs6Z+rGTprSn SiPqQiIedJY9neYtn3lHnmpTpEM8JDdjylCcjrOhN51pR/kpzWoeUZtBtepQMdlZVINyVaog HWhJYerJPsLPleB0ajxXKU4tAlOtMl1qWl05TBW2NHPdxChWiVpVks5yiLH8KTKDmklOBo+l xiPl6ggIVZJetX3NS58ED6rGDP6yeX01XxIdW8EeclCfIwzr4d7XNMUW0JN/ex8pH6dHxKZ2 sVeEZzjzpr8EqrOehi3tWss2QepVdbcUNSIboclMIWr2s561LFgb+9h8cRBguRsay577rmpS t7rWvS52s6vd7XK3u979rnSh60Dwkre85j0vd8Wr3vWyt73ufS984yvf+dL3ZAEBADs= ------=_NextPart_000_0004_01C65BCC.3363EAC0-- From mpls-bounces@lists.ietf.org Mon Apr 10 05:27:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSseZ-0007Wb-0K; Mon, 10 Apr 2006 05:25:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSseX-0007WW-EQ for mpls@ietf.org; Mon, 10 Apr 2006 05:25:45 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSseX-0000Gg-2V for mpls@ietf.org; Mon, 10 Apr 2006 05:25:45 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 11:25:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs Date: Mon, 10 Apr 2006 11:25:40 +0200 Message-ID: <5A0FF108221C7C4E85738678804B567C0327B7E9@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs Thread-Index: AcZbR1+SBsJJsOnuQLCI23Y0E3362gBK+RDQ From: "DECRAENE Bruno RD-CORE-ISS" To: "Dutta, Pranjal" , X-OriginalArrivalTime: 10 Apr 2006 09:25:42.0771 (UTC) FILETIME=[BD465430:01C65C80] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Pranjal, all, That's a good question; thanks for asking ;-) Currently, as per RFC 3036 section 3.5.7.1, Ru should perform a longest = match. But we believe that in some situation (eg use of IGP areas), we could = benefit from doing a longest match as this would relax the need for = leaking in the IGP all the /32 prefixes across area boundaries. To = initiate discussion on this point, we've written = draft-decraene-mpls-ldp-interarea-01.txt and presented it in Vancouver ( = http://www3.ietf.org/proceedings/05nov/slides/mpls-4.pdf ) Right after this presentation, it was suggested to gather feed-back on = the usefulness of this ID before moving forward.=20 Pranjal, all, could you please tell us whether you think that it is = worth being pursed? Best regards, Bruno ________________________________________ From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com]=20 Sent: Saturday, April 08, 2006 10:11 PM To: mpls@ietf.org Subject: [mpls] One LDP Implementation specific question of receive = labelmapping for prefix FECs Hi, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 I have a basic confusion on = the "Label Mapping Receive Procedure" explained in the appendix of RFC = 3036. One step says "Find the FEC next hop". When Ru receives a label = mapping for a FEC of type IPv4/v6 prefix from Rd, the next hop for the = FEC can be determined after route lookup. Now here, for looking up the = FEC at Ru do we need to do exact match or Longest prefix match? It is = quite possible that the prefix as FEC mapped by Rd may be within a = supernetted =A0prefix at Ru. The reason why I am asking is I guess the = implications could be different based on whether LSR is merge capable or = non-merge capable. Thanks in advance, Pranjal _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Apr 10 07:21:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSuQZ-0001qY-QN; Mon, 10 Apr 2006 07:19:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSuQY-0001qT-QN for mpls@ietf.org; Mon, 10 Apr 2006 07:19:26 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSuQY-0004fu-Ib for mpls@ietf.org; Mon, 10 Apr 2006 07:19:26 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 10 Apr 2006 04:19:26 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,107,1144047600"; d="scan'208"; a="25534917:sNHT21759120" 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 k3ABJPWc019623; Mon, 10 Apr 2006 07:19:25 -0400 (EDT) Message-Id: <200604101119.k3ABJPWc019623@rtp-core-1.cisco.com> To: "DECRAENE Bruno RD-CORE-ISS" Subject: Re: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs In-Reply-To: Message from "DECRAENE Bruno RD-CORE-ISS" of "Mon, 10 Apr 2006 11:25:40 +0200." <5A0FF108221C7C4E85738678804B567C0327B7E9@ftrdmel3.rd.francetelecom.fr> Date: Mon, 10 Apr 2006 07:19:25 -0400 From: Bob Thomas X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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: , Errors-To: mpls-bounces@lists.ietf.org Hi Bruno, > Hi Pranjal, all, > > That's a good question; thanks for asking ;-) > > Currently, as per RFC 3036 section 3.5.7.1, Ru should perform a longest = > match. I think you meant exact match. draft-ietf-mpls-rfc3036bis-03.txt: An LSR receiving a Label Mapping message from a downstream LSR for a Prefix SHOULD NOT use the label for forwarding unless its routing ta- ble contains an entry that exactly matches the FEC Element. *************** Bob > But we believe that in some situation (eg use of IGP areas), we could = > benefit from doing a longest match as this would relax the need for = > leaking in the IGP all the /32 prefixes across area boundaries. To = > initiate discussion on this point, we've written = > draft-decraene-mpls-ldp-interarea-01.txt and presented it in Vancouver ( = > http://www3.ietf.org/proceedings/05nov/slides/mpls-4.pdf ) > > Right after this presentation, it was suggested to gather feed-back on = > the usefulness of this ID before moving forward.=20 > > Pranjal, all, could you please tell us whether you think that it is = > worth being pursed? > > > Best regards, > Bruno > > > > ________________________________________ > From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com]=20 > Sent: Saturday, April 08, 2006 10:11 PM > To: mpls@ietf.org > Subject: [mpls] One LDP Implementation specific question of receive = > labelmapping for prefix FECs > > Hi, > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 I have a basic confusion on = > the "Label Mapping Receive Procedure" explained in the appendix of RFC = > 3036. One step says "Find the FEC next hop". When Ru receives a label = > mapping for a FEC of type IPv4/v6 prefix from Rd, the next hop for the = > FEC can be determined after route lookup. Now here, for looking up the = > FEC at Ru do we need to do exact match or Longest prefix match? It is = > quite possible that the prefix as FEC mapped by Rd may be within a = > supernetted =A0prefix at Ru. The reason why I am asking is I guess the = > implications could be different based on whether LSR is merge capable or = > non-merge capable. > > Thanks in advance, > Pranjal > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Apr 10 07:52:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSuuy-0004M1-Rt; Mon, 10 Apr 2006 07:50:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRX5d-0000ta-AD for mpls@lists.ietf.org; Thu, 06 Apr 2006 12:12:09 -0400 Received: from tlv1.axerra.com ([80.74.100.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRX5c-0006DG-K9 for mpls@lists.ietf.org; Thu, 06 Apr 2006 12:12:09 -0400 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Apr 2006 19:08:20 +0200 Message-ID: From: Sasha Vainshtein To: 'Greg Jones' Subject: RE: [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns" Date: Thu, 6 Apr 2006 19:08:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 X-Mailman-Approved-At: Mon, 10 Apr 2006 07:50:51 -0400 Cc: mpls@lists.ietf.org, mark.jones@sprint.com, maeda@ansl.ntt.co.jp, info@mfaforum.org, Ghani.Abbas@marconi.com, sbrim@cisco.com, fenner@research.att.com, rcallon@juniper.net, betts01@nortel.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Greg and all, In your message to the MPLS WG you jave stated state that reservation of labels 16 to 31 was seen as not leading to any interoperability issues between MPLS and T-MPLS because the label allocation on a link is defined in IETF RFCs as a local matter for any MPLS device Please note that Section 3.14 of RFC 3031 "Multiprotocol Label Switching Architecture" defines at least two types of label spaces in a LSR: - per-interface - per-platform. (Other types of label spaces are not precluded by RFC 3031.) To the best of my knowledge, both types of label spaces are widely used in the MPLS networks already deployed. In certain cases (e.g., when dealing with MPLS Pseudo-Wire labels), usage of per-platform label space is MANDATORY. (See http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-17.txt which has been already approvde for publication as a Standards Track RFC.) Please note also that encoding of the MPLS Shim header as defined in RFC 3032 does not distinguish between these two types of label spaces. I am hence concerned that reservation of additional labels may cause interoperability issues between T-MPLS and existing LSRs using per-platform label allocation. At the very least it seems that your analysis of the possible interoperability use cases does not consider the situation when per-platform label space is used and includes labels reserved for T-MPLS. Regards, Sasha > -----Original Message----- > From: Greg Jones [mailto:tsbsg15@itu.int] > Sent: Sunday, April 02, 2006 9:59 PM > To: George Swallow; Loa Andersson > Cc: mpls@lists.ietf.org; mark.jones@sprint.com; maeda@ansl.ntt.co.jp; > info@mfaforum.org; Ghani.Abbas@marconi.com; sbrim@cisco.com; > fenner@research.att.com; statements@ietf.org; rcallon@juniper.net; > tsbsg15@itu.int; betts01@nortel.com > Subject: [mpls] New Liaison Statement, "T-MPLS Consented > Recommendations" > > > > Title: T-MPLS Consented Recommendations > Submission Date: 2006-04-02 > URL of the IETF Web page: > https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=207 > Please reply by 2006-04-17 > > From: Greg Jones(ITU-T SG 15) > To: IETF MPLS WG, CC: MFA Forum(George Swallow > , Loa Andersson ) > Cc: info@mfaforum.org > maeda@ansl.ntt.co.jp > sjtrowbridge@lucent.com > rcallon@juniper.net > fenner@research.att.com > sob@harvard.edu > sbrim@cisco.com > mpls@lists.ietf.org > Reponse Contact: tsbsg15@itu.int > Technical Contact: Ghani.Abbas@marconi.com > mark.jones@sprint.com > betts01@nortel.com > Purpose: For action > Body: We apologize for not having sent a liaison regarding > three consented Recommendations related to > T-MPLS. The intent of these Recommendations is not to change > MPLS but rather to identify a > subset of existing MPLS necessary and sufficient to provide > connection-oriented packet transport. > The approach to the work was to make a profile of the MPLS > data plane functionalities defined in > IETF RFCs using the description of MPLS provided in G.8110 > (which was approved last year). > The intended application of this profile is to provide a > connection-oriented packet transport > network. > The focus of the three new recommendations is on the data > plane aspects of T-MPLS. Control plane > aspects are currently for further study and the work on this > subject is starting. > According to our work methodology the T-MPLS definitions are > split into the three main > Recommendations that have been consented in February 2006: > * G.8110.1 dealing with the T-MPLS Architecture > * G.8112 dealing with T-MPLS interface specification > * G.8121 dealing with T-MPLS equipment functional specification > A brief high-level introduction of the essential features and > selected options for Transport MPLS > can be found in section 6/G.8110.1. > The objective of the work done by ITU-T SG15 was to define a > way to use MPLS as a connection- > oriented packet-based transport solution for packet aware > transport networks that can support both > packet and circuit (e.g. SDH, OTH or WDM) switching > technologies under a common operation, > control and management paradigm. For this purpose T-MPLS > deploys the MPLS frame format, > Client to MPLS mapping and MPLS to MPLS multiplexing and > complements this with transport > network OAM (Y.1711), nested connection monitoring requiring > the labels to be present up to the > final node in the network, protection switching > (Y.1720/G.8131), transport network based control > and management planes, maintaining frame ordering and a > restricted number of classes of > service/queues. > * MPLS has many applications and it is desirable to > identify a subset of MPLS technology that > provides the necessary and sufficient functionality for > transport applications. > We have indicated below some of the options we have selected :- > * In IETF RFCs the usage of PHP is optional. We decided > not to use it in order to simplify OAM > procedures > * In IETF RFCs the usage of merging is optional. We > decided not to use it in order to simplify > OAM procedures and also because the relative lower number of > LSPs to be supported is not > considered a major scaling issue > * The usage of ECMP is optional. We decided not to use it > in order to simplify OAM procedures > * Leaving labels 16-31 for further study was seen as a no > change because the label allocation on a > link is defined in IETF RFCs as a local matter for any MPLS device. > We are not expecting that the current version of the > specification is going to create any > interoperability issue. We envisage two possible cases of > interoperability: > 1. Interoperability between a T-MPLS box and an existing > full-featured and fully configurable > MPLS box can be solved by configuring the MPLS box to use the > same options selected by T- > MPLS (T-MPLS being a profile of MPLS this should be > possible). In this case the link between > the two boxes is a T-MPLS link and in the scope of our > Recommendations. > 2. Interoperability between a transport platform > supporting T-MPLS and an existing MPLS box > that uses a different option selection than T-MPLS, should be > solved by the transport platform. > In this case the link between the transport platform and the > MPLS box is not a T-MPLS link and > therefore it is outside the scope of T-MPLS recommendations. > We are looking for cooperation > with IETF to develop the detailed specification of this case. > Please find attached the text of the consented > Recommendations. Please note that some minor > modifications may be made to these draft Recommendations as a > result of comments made during > the approval process > We will appreciate your comments and suggestions in relation > to the initial scope of T-MPLS as a > packet transport network technology. > We are planning to review your comments during the next > meeting that is planned in Kobe (Japan) > on 22-27 April 2006. Results of the comments will be included > into our future work (e.g. corrigenda > or amendments) on T-MPLS Recommendations. Amendments of > T-MPLS Recommendations are > already in our plan for the next SG15 plenary meeting in > November 2006.We are looking forward > for future cooperation with you in T-MPLS data plane and > control plane evolution. > > Attachments: Consented Text of G.8110.1, G.8112, G.8121 > Attachment(s): > Consented Text of G.8110.1 (https://datatracker.ietf.org/documents/LIAISON/file288.zip) Consented Text of G.8112 (https://datatracker.ietf.org/documents/LIAISON/file289.zip) Consented Text of G.8121 (https://datatracker.ietf.org/documents/LIAISON/file290.zip) _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Apr 10 08:24:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSvQ1-0000Wo-7R; Mon, 10 Apr 2006 08:22:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSvIu-0007kD-2y for mpls@ietf.org; Mon, 10 Apr 2006 08:15:36 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSvEI-0006j6-Ef for mpls@ietf.org; Mon, 10 Apr 2006 08:10:50 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 14:10:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs Date: Mon, 10 Apr 2006 14:10:46 +0200 Message-ID: <5A0FF108221C7C4E85738678804B567C0327B8DB@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs Thread-Index: AcZckKF9OrlW5MqTQPmOsVTGHe5ehwABlKyQ From: "DECRAENE Bruno RD-CORE-ISS" To: "Bob Thomas" X-OriginalArrivalTime: 10 Apr 2006 12:10:47.0908 (UTC) FILETIME=[CD324A40:01C65C97] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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: , Errors-To: mpls-bounces@lists.ietf.org Hi Bob, =20 > Hi Bruno, >=20 > > Hi Pranjal, all, > > > > That's a good question; thanks for asking ;-) > > > > Currently, as per RFC 3036 section 3.5.7.1, Ru should perform a longest =3D > > match. >=20 > I think you meant exact match. [Bruno D:] Indeed. Thanks for the rectification. =20 > draft-ietf-mpls-rfc3036bis-03.txt: >=20 > An LSR receiving a Label Mapping message from a downstream LSR for a > Prefix SHOULD NOT use the label for forwarding unless its routing ta- > ble contains an entry that exactly matches the FEC Element. > *************** >=20 >=20 > Bob >=20 >=20 > > But we believe that in some situation (eg use of IGP areas), we could =3D > > benefit from doing a longest match as this would relax the need for =3D > > leaking in the IGP all the /32 prefixes across area boundaries. To = =3D > > initiate discussion on this point, we've written =3D > > draft-decraene-mpls-ldp-interarea-01.txt and presented it in Vancouver ( =3D > > http://www3.ietf.org/proceedings/05nov/slides/mpls-4.pdf ) > > > > Right after this presentation, it was suggested to gather feed-back on =3D > > the usefulness of this ID before moving forward.=3D20 > > > > Pranjal, all, could you please tell us whether you think that it is =3D > > worth being pursed? > > > > > > Best regards, > > Bruno > > > > > > > > ________________________________________ > > From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com]=3D20 > > Sent: Saturday, April 08, 2006 10:11 PM > > To: mpls@ietf.org > > Subject: [mpls] One LDP Implementation specific question of receive =3D > > labelmapping for prefix FECs > > > > Hi, > > = =3DA0=3DA0=3DA0=3DA0=3DA0=3DA0=3DA0=3DA0=3DA0=3DA0=3DA0=3DA0=3DA0=3DA0 I = have a basic confusion on =3D > > the "Label Mapping Receive Procedure" explained in the appendix of RFC =3D > > 3036. One step says "Find the FEC next hop". When Ru receives a label =3D > > mapping for a FEC of type IPv4/v6 prefix from Rd, the next hop for the =3D > > FEC can be determined after route lookup. Now here, for looking up the =3D > > FEC at Ru do we need to do exact match or Longest prefix match? It is =3D > > quite possible that the prefix as FEC mapped by Rd may be within a = =3D > > supernetted =3DA0prefix at Ru. The reason why I am asking is I guess the =3D > > implications could be different based on whether LSR is merge capable or =3D > > non-merge capable. > > > > Thanks in advance, > > Pranjal > > > > > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/mpls > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Apr 10 09:37:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwXm-0003vp-SB; Mon, 10 Apr 2006 09:35:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwXk-0003vi-TT for mpls@ietf.org; Mon, 10 Apr 2006 09:35:00 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=oberon.imc.kth.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSwXj-0001fc-G8 for mpls@ietf.org; Mon, 10 Apr 2006 09:35:00 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id k3ADPCX2010724 for ; Mon, 10 Apr 2006 15:25:12 +0200 Received: from [127.0.0.1] ([172.16.2.231]) by mail1.imc.kth.se; Mon, 10 Apr 2006 15:33:58 +0200 Message-ID: <443A5EC4.9040801@pi.se> Date: Mon, 10 Apr 2006 15:33:56 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [mpls] wg last call draft-ietf-mpls-over-l2tpv3-01 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: , Errors-To: mpls-bounces@lists.ietf.org Working Group, this mail initiates a two week working last call on: draft-ietf-mpls-over-l2tpv3-01 Please send your comment to the working mailing list or directly to the working group co-chairs. The working group last call ends eob April 24. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Apr 10 14:11:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT0p9-0007bq-7E; Mon, 10 Apr 2006 14:09:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT0p7-0007bl-6a for mpls@ietf.org; Mon, 10 Apr 2006 14:09:13 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT0p6-0004Xg-06 for mpls@ietf.org; Mon, 10 Apr 2006 14:09:13 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 10 Apr 2006 14:09:12 -0400 X-IronPort-AV: i="4.04,108,1144036800"; d="scan'208"; a="86118724:sNHT27225812" 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 k3AI9BWc013895; Mon, 10 Apr 2006 14:09:11 -0400 (EDT) Message-Id: <200604101809.k3AI9BWc013895@rtp-core-1.cisco.com> To: "Dutta, Pranjal" Subject: Re: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs In-reply-to: Your message of Sun, 09 Apr 2006 01:40:40 +0530. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 10 Apr 2006 14:09:11 -0400 From: Eric Rosen X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org > When Ru receives a label mapping for a FEC of type IPv4/v6 prefix from Rd, > the next hop for the FEC can be determined after route lookup. Now here, > for looking up the FEC at Ru do we need to do exact match or Longest > prefix match? It is quite possible that the prefix as FEC mapped by Rd may > be within a supernetted prefix at Ru. It's a little hard to understand what you're asking. By definition, one cannot change the FEC in mid-LSP. If the FEC is an address prefix, and you reach a point where that address prefix is not in the routing table, then the LSP terminates. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Apr 10 23:38:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT9gN-0004K3-0G; Mon, 10 Apr 2006 23:36:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT9gL-0004JO-Ba for mpls@ietf.org; Mon, 10 Apr 2006 23:36:45 -0400 Received: from mgw1.noc.ntt.com ([210.163.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT9gI-0004r2-Nz for mpls@ietf.org; Mon, 10 Apr 2006 23:36:45 -0400 Received: from mop1.noc.ntt.com by mgw1.noc.ntt.com (NTT-Com MailSV) with ESMTP id k3B3adoD027486 for ; Tue, 11 Apr 2006 12:36:40 +0900 (JST) Received: from mip1.noc.ntt.com (mvi1.noc.ntt.com) by mop1.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0IXJ007JEGP3S6@ntt.com> for mpls@ietf.org; Tue, 11 Apr 2006 12:36:40 +0900 (JST) Date: Tue, 11 Apr 2006 12:36:39 +0900 From: "Yuichi Ikejiri" Subject: Re: [mpls] Comments on draft-vasseur-mpls-number-0-bw-te-lsps-00 ? In-reply-to: To: mpls@ietf.org Message-id: <20060411114128.5901.Y.IKEJIRI@ntt.com> MIME-version: 1.0 X-Mailer: Becky! ver. 2.21.01 [ja] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi, I would like to support this draft. This draft would be very useful to allow us to load balance lsps across the whole network from the perspective of a service provider. In addition, JL's suggention would be also useful when we use 0bw lsps and non-0bw lsps in the network. Thanks, Yuichi On Mon, 20 Mar 2006 10:15:09 -0600 "JP Vasseur" wrote: > Dear WG, > > Right after the presentation this morning, it was suggested to gather > feed-back on the usefulness of this ID before moving forward. I got > some feed-back off-line and on-line (Kenji - KDDI). > > Could you tell me whether you think that it is worth being pursed ? > > Send comments if any. > > Thanks. > > JP. > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 00:47:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTAkv-0002tv-Hq; Tue, 11 Apr 2006 00:45:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTAkt-0002tq-Vk for mpls@ietf.org; Tue, 11 Apr 2006 00:45:31 -0400 Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTAkq-0007IA-Jl for mpls@ietf.org; Tue, 11 Apr 2006 00:45:31 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id VAA10051; Mon, 10 Apr 2006 21:45:25 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs Date: Tue, 11 Apr 2006 10:15:24 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs Thread-Index: AcZcyeW7LxvQuH+qRxm/rhPwQ23RdwAVqKrA From: "Dutta, Pranjal" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: , Errors-To: mpls-bounces@lists.ietf.org Hi Eric, As per RFC 3036 Label mapping receive procedures, when Ru received a label mapping from Rd for a FEC x, Ru need to find an "exact" match of the FEC x(IPv4/V6 prefix) in its route table. In Inter-IGP-area or inter-AS case the routes from Rd would be summarized to Ru and in such a case Ru MAY not find the exact match for such FEC x. In terms of RFC 3036 then Ru MAY not find exact match for the FEC received from Rd in its route table and no further action at Ru. My question was why Ru can't we do a longest prefix match for the FEC x as LPM means it can be reached by a downstream Rd?=20 Thanks, Pranjal -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com]=20 Sent: Monday, 10 April, 2006 11:39 PM To: Dutta, Pranjal Cc: mpls@ietf.org Subject: Re: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs=20 > When Ru receives a label mapping for a FEC of type IPv4/v6 prefix from Rd, > the next hop for the FEC can be determined after route lookup. Now here, > for looking up the FEC at Ru do we need to do exact match or Longest > prefix match? It is quite possible that the prefix as FEC mapped by Rd may > be within a supernetted prefix at Ru.=20 It's a little hard to understand what you're asking. By definition, one cannot change the FEC in mid-LSP. If the FEC is an address prefix, and you reach a point where that address prefix is not in the routing table, then the LSP terminates.=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 07:04:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTGdx-0004MV-2v; Tue, 11 Apr 2006 07:02:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTGdv-0004ML-FT for mpls@ietf.org; Tue, 11 Apr 2006 07:02:43 -0400 Received: from imo-d02.mx.aol.com ([205.188.157.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTGdv-0004US-5C for mpls@ietf.org; Tue, 11 Apr 2006 07:02:43 -0400 Received: from ewgray2k@netscape.net by imo-d02.mx.aol.com (mail_out_v38_r7.3.) id h.1b4.11f55f2a (22682); Tue, 11 Apr 2006 07:02:28 -0400 (EDT) Received: from [192.168.3.101] (c-24-128-207-21.hsd1.nh.comcast.net [24.128.207.21]) by air-in04.mx.aol.com (v108_r3.6) with ESMTP id MAILININ43-589a443b8cc428; Tue, 11 Apr 2006 07:02:28 -0400 Message-ID: <443B8CA8.50806@netscape.net> Date: Tue, 11 Apr 2006 07:02:00 -0400 From: Eric W Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Dutta, Pranjal" Subject: Re: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs References: In-Reply-To: X-AOL-IP: 24.128.207.21 X-Mailer: Unknown (No Version) X-Spam-Flag: NO X-Spam-Score: 0.1 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@GraIyMage.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0145253848==" Errors-To: mpls-bounces@lists.ietf.org --===============0145253848== Content-Type: multipart/alternative; boundary="------------000504040301050601080907" --------------000504040301050601080907 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The implementation MUST do an exact match, as downstream LSRs will forward based only on the label. Because they do not (typically) perform a route look-up on the label encapsulated inner IP packet, there is no reason to expect a downstream LSR to be able to separate a flow based on longest match when the routes further downstream are distinct for "longer matches". Dutta, Pranjal wrote: >Hi Eric, > As per RFC 3036 Label mapping receive procedures, when Ru >received a label mapping from Rd for a FEC x, Ru need to find an "exact" >match of the FEC x(IPv4/V6 prefix) in its route table. In Inter-IGP-area >or inter-AS case the routes from Rd would be summarized to Ru and in >such a case Ru MAY not find the exact match for such FEC x. In terms of >RFC 3036 then Ru MAY not find exact match for the FEC received from Rd >in its route table and no further action at Ru. My question was why Ru >can't we do a longest prefix match for the FEC x as LPM means it can be >reached by a downstream Rd? > >Thanks, >Pranjal > >-----Original Message----- >From: Eric Rosen [mailto:erosen@cisco.com] >Sent: Monday, 10 April, 2006 11:39 PM >To: Dutta, Pranjal >Cc: mpls@ietf.org >Subject: Re: [mpls] One LDP Implementation specific question of receive >label mapping for prefix FECs > > > > >>When Ru receives a label mapping for a FEC of type IPv4/v6 prefix from >> >> >Rd, > > >>the next hop for the FEC can be determined after route lookup. Now >> >> >here, > > >>for looking up the FEC at Ru do we need to do exact match or >> >> >Longest > > >>prefix match? It is quite possible that the prefix as FEC mapped by Rd >> >> >may > > >>be within a supernetted prefix at Ru. >> >> > >It's a little hard to understand what you're asking. By definition, >one >cannot change the FEC in mid-LSP. If the FEC is an address prefix, and >you >reach a point where that address prefix is not in the routing table, >then >the LSP terminates. > > > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/mpls > > > > > --------------000504040301050601080907 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The implementation MUST do an exact match, as downstream LSRs will forward based
only on the label.  Because they do not (typically) perform a route look-up on the label
encapsulated inner IP packet, there is no reason to expect a downstream LSR to be able
to separate a flow based on longest match when the routes further downstream are distinct
for "longer matches".

Dutta, Pranjal wrote:
Hi Eric,
          As per RFC 3036 Label mapping receive procedures, when Ru
received a label mapping from Rd for a FEC x, Ru need to find an "exact"
match of the FEC x(IPv4/V6 prefix) in its route table. In Inter-IGP-area
or inter-AS case the routes from Rd would be summarized to Ru and in
such a case Ru MAY not find the exact match for such FEC x. In terms of
RFC 3036 then Ru MAY not find exact match for the FEC received from Rd
in its route table and no further action at Ru. My question was why Ru
can't we do a longest prefix match for the FEC x as LPM means it can be
reached by a downstream Rd? 

Thanks,
Pranjal

-----Original Message-----
From: Eric Rosen [mailto:erosen@cisco.com] 
Sent: Monday, 10 April, 2006 11:39 PM
To: Dutta, Pranjal
Cc: mpls@ietf.org
Subject: Re: [mpls] One LDP Implementation specific question of receive
label mapping for prefix FECs 


  
When Ru receives a label mapping for a FEC of type IPv4/v6 prefix from
    
Rd,
  
the next hop  for the FEC can be determined after  route lookup. Now
    
here,
  
for looking  up the  FEC at Ru  do we  need to do  exact match  or
    
Longest
  
prefix match? It is quite possible that the prefix as FEC mapped by Rd
    
may
  
be within a supernetted prefix at Ru. 
    

It's a  little hard  to understand what  you're asking.  By  definition,
one
cannot change the FEC in mid-LSP.  If  the FEC is an address prefix, and
you
reach a  point where that address prefix  is not in the  routing table,
then
the LSP terminates. 



_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
--------------000504040301050601080907-- --===============0145253848== 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 --===============0145253848==-- From mpls-bounces@lists.ietf.org Tue Apr 11 07:06:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTGfb-0004qx-DT; Tue, 11 Apr 2006 07:04:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSy7T-0005Jx-7h for mpls@lists.ietf.org; Mon, 10 Apr 2006 11:15:59 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSy7S-00063D-H0 for mpls@lists.ietf.org; Mon, 10 Apr 2006 11:15:59 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 10 Apr 2006 08:15:31 -0700 X-IronPort-AV: i="4.04,108,1144047600"; d="scan'208"; a="1793412672:sNHT1962559700" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k3AFFGZ0007228; Mon, 10 Apr 2006 08:15:30 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Apr 2006 11:15:27 -0400 Received: from [10.83.15.57] ([10.83.15.57]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Apr 2006 11:15:26 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4EC42464-B4C2-4A6B-B268-E26B5480DB95@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented Recommendations" Date: Mon, 10 Apr 2006 11:15:25 -0400 To: Greg Jones(ITU-T SG 15) X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 10 Apr 2006 15:15:26.0804 (UTC) FILETIME=[98BBA940:01C65CB1] X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 X-Mailman-Approved-At: Tue, 11 Apr 2006 07:04:25 -0400 Cc: mpls@lists.ietf.org, mark.jones@sprint.com, maeda@ansl.ntt.co.jp, info@mfaforum.org, Ghani.Abbas@marconi.com, Scott Brim W , "Bill \(E-mail\) Fenner" , statements@ietf.org, Ross Callon , betts01@nortel.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi, A few things in the ITU T-MPLS document concern me: 1) The document itself constitutes what is essentially two things: an protocol specification and an implementation guideline. For this reason, I first suggest that this document needs to be split into two: one that specifies the label range allocation (as well as requests it from the IETF), and a second that specifies the implementation guideline. I also suggest removal of "MPLS" from the name. This is very confusing, and implies that this document is some new standard for MPLS, whereas what it really specifies (sans the label range allocation and the OAM) is a subset of MPLS functionality. 2) With regard to the label range reservation, I am troubled by this because MPLS has been widely deployed without the said reserved label range. Deployment of LSRs that suddenly use this special label range will most likely lead to interoperability issues. I am also troubled by the lack of definition of what the reserved labels should be used for. If in the future, these labels are defined in a manner that is incompatible with existing LSRs, this will pose a significant hurdle to deployments. Again, a separate document that requests the label range, as well as specifies what they are to be used for is appropriate. 3) The OAM as specified does not meet the IETF's requirements for OAM specified in RFC4377. Y.1711 is not suitable for environments where PHP is enabled, and it also has other deficiencies such as a lack of tracing functionality, and cannot handle Equal Cost Multi-Path (ECMP) LSPs. In particular, section 4.3 of RFC4377 stipulates that path characterization functions must be able to work in these cases: 4.3. Path Characterization The path characterization function is the ability to reveal details of LSR forwarding operations. These details can then be compared during subsequent testing relevant to OAM functionality. This includes but is not limited to: - consistent use of pipe or uniform time to live (TTL) models by an LSR [RFC3443]. - sufficient details that allow the test origin to exercise all path permutations related to load spreading (e.g., ECMP). - stack operations performed by the LSR, such as pushes, pops, and TTL propagation at penultimate hop LSRs. I suggest replacing the reference to Y.1711 with a reference to rfc4377, rfc4378, and rfc4379. --Tom > Title: T-MPLS Consented Recommendations > Submission Date: 2006-04-02 > URL of the IETF Web page: https://datatracker.ietf.org/public/ > liaison_detail.cgi?detail_id=207 > Please reply by 2006-04-17 > > From: Greg Jones(ITU-T SG 15) > To: IETF MPLS WG, CC: MFA Forum(George Swallow , > Loa Andersson ) > Cc: info@mfaforum.org > maeda@ansl.ntt.co.jp > sjtrowbridge@lucent.com > rcallon@juniper.net > fenner@research.att.com > sob@harvard.edu > sbrim@cisco.com > mpls@lists.ietf.org > Reponse Contact: tsbsg15@itu.int > Technical Contact: Ghani.Abbas@marconi.com > mark.jones@sprint.com > betts01@nortel.com > Purpose: For action > Body: We apologize for not having sent a liaison regarding three > consented Recommendations related to > T-MPLS. The intent of these Recommendations is not to change MPLS > but rather to identify a > subset of existing MPLS necessary and sufficient to provide > connection-oriented packet transport. > The approach to the work was to make a profile of the MPLS data > plane functionalities defined in > IETF RFCs using the description of MPLS provided in G.8110 (which > was approved last year). > The intended application of this profile is to provide a connection- > oriented packet transport > network. > The focus of the three new recommendations is on the data plane > aspects of T-MPLS. Control plane > aspects are currently for further study and the work on this > subject is starting. > According to our work methodology the T-MPLS definitions are split > into the three main > Recommendations that have been consented in February 2006: > * G.8110.1 dealing with the T-MPLS Architecture > * G.8112 dealing with T-MPLS interface specification > * G.8121 dealing with T-MPLS equipment functional specification > A brief high-level introduction of the essential features and > selected options for Transport MPLS > can be found in section 6/G.8110.1. > The objective of the work done by ITU-T SG15 was to define a way to > use MPLS as a connection- > oriented packet-based transport solution for packet aware transport > networks that can support both > packet and circuit (e.g. SDH, OTH or WDM) switching technologies > under a common operation, > control and management paradigm. For this purpose T-MPLS deploys > the MPLS frame format, > Client to MPLS mapping and MPLS to MPLS multiplexing and > complements this with transport > network OAM (Y.1711), nested connection monitoring requiring the > labels to be present up to the > final node in the network, protection switching (Y.1720/G.8131), > transport network based control > and management planes, maintaining frame ordering and a restricted > number of classes of > service/queues. > * MPLS has many applications and it is desirable to identify a > subset of MPLS technology that > provides the necessary and sufficient functionality for transport > applications. > We have indicated below some of the options we have selected :- > * In IETF RFCs the usage of PHP is optional. We decided not to use > it in order to simplify OAM > procedures > * In IETF RFCs the usage of merging is optional. We decided not to > use it in order to simplify > OAM procedures and also because the relative lower number of LSPs > to be supported is not > considered a major scaling issue > * The usage of ECMP is optional. We decided not to use it in order > to simplify OAM procedures > * Leaving labels 16-31 for further study was seen as a no change > because the label allocation on a > link is defined in IETF RFCs as a local matter for any MPLS device. > We are not expecting that the current version of the specification > is going to create any > interoperability issue. We envisage two possible cases of > interoperability: > 1. Interoperability between a T-MPLS box and an existing full- > featured and fully configurable > MPLS box can be solved by configuring the MPLS box to use the same > options selected by T- > MPLS (T-MPLS being a profile of MPLS this should be possible). In > this case the link between > the two boxes is a T-MPLS link and in the scope of our > Recommendations. > 2. Interoperability between a transport platform supporting T-MPLS > and an existing MPLS box > that uses a different option selection than T-MPLS, should be > solved by the transport platform. > In this case the link between the transport platform and the MPLS > box is not a T-MPLS link and > therefore it is outside the scope of T-MPLS recommendations. We are > looking for cooperation > with IETF to develop the detailed specification of this case. > Please find attached the text of the consented Recommendations. > Please note that some minor > modifications may be made to these draft Recommendations as a > result of comments made during > the approval process > We will appreciate your comments and suggestions in relation to the > initial scope of T-MPLS as a > packet transport network technology. > We are planning to review your comments during the next meeting > that is planned in Kobe (Japan) > on 22-27 April 2006. Results of the comments will be included into > our future work (e.g. corrigenda > or amendments) on T-MPLS Recommendations. Amendments of T-MPLS > Recommendations are > already in our plan for the next SG15 plenary meeting in November > 2006.We are looking forward > for future cooperation with you in T-MPLS data plane and control > plane evolution. > > Attachments: Consented Text of G.8110.1, G.8112, G.8121 > Attachment(s): > Consented Text of G.8110.1 (https://datatracker.ietf.org/ > documents/LIAISON/file288.zip) > Consented Text of G.8112 (https://datatracker.ietf.org/ > documents/LIAISON/file289.zip) > Consented Text of G.8121 (https://datatracker.ietf.org/ > documents/LIAISON/file290.zip) > > > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 09:27:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTIre-0004x5-OL; Tue, 11 Apr 2006 09:25:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTIrc-0004wx-Hc for mpls@lists.ietf.org; Tue, 11 Apr 2006 09:25:00 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTIrZ-0001e0-Sa for mpls@lists.ietf.org; Tue, 11 Apr 2006 09:25:00 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 11 Apr 2006 06:24:58 -0700 X-IronPort-AV: i="4.04,112,1144047600"; d="scan'208"; a="267953994:sNHT40535052" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k3BDOu1j029719; Tue, 11 Apr 2006 06:24:57 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 09:24:56 -0400 Received: from [10.83.15.57] ([10.83.15.57]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 09:24:55 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8452A02A-4204-4F2F-946E-DA644CF50F45@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented Recommendations" Date: Tue, 11 Apr 2006 09:24:55 -0400 To: mpls@lists.ietf.org X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 11 Apr 2006 13:24:55.0779 (UTC) FILETIME=[52BF4B30:01C65D6B] X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org [Resending to mpls list as I got a warning from the mailer that there was a suspicious number of recipients, so I am not sure it was delivered.] Hi, A few things in the ITU T-MPLS document concern me: 1) The document itself constitutes what is essentially two things: an protocol specification and an implementation guideline. For this reason, I first suggest that this document needs to be split into two: one that specifies the label range allocation (as well as requests it from the IETF), and a second that specifies the implementation guideline. I also suggest removal of "MPLS" from the name. This is very confusing, and implies that this document is some new standard for MPLS, whereas what it really specifies (sans the label range allocation and the OAM) is a subset of MPLS functionality. 2) With regard to the label range reservation, I am troubled by this because MPLS has been widely deployed without the said reserved label range. Deployment of LSRs that suddenly use this special label range will most likely lead to interoperability issues. I am also troubled by the lack of definition of what the reserved labels should be used for. If in the future, these labels are defined in a manner that is incompatible with existing LSRs, this will pose a significant hurdle to deployments. Again, a separate document that requests the label range, as well as specifies what they are to be used for is appropriate. 3) The OAM as specified does not meet the IETF's requirements for OAM specified in RFC4377. Y.1711 is not suitable for environments where PHP is enabled, and it also has other deficiencies such as a lack of tracing functionality, and cannot handle Equal Cost Multi-Path (ECMP) LSPs. In particular, section 4.3 of RFC4377 stipulates that path characterization functions must be able to work in these cases: 4.3. Path Characterization The path characterization function is the ability to reveal details of LSR forwarding operations. These details can then be compared during subsequent testing relevant to OAM functionality. This includes but is not limited to: - consistent use of pipe or uniform time to live (TTL) models by an LSR [RFC3443]. - sufficient details that allow the test origin to exercise all path permutations related to load spreading (e.g., ECMP). - stack operations performed by the LSR, such as pushes, pops, and TTL propagation at penultimate hop LSRs. I suggest replacing the reference to Y.1711 with a reference to rfc4377, rfc4378, and rfc4379. --Tom > Title: T-MPLS Consented Recommendations > Submission Date: 2006-04-02 > URL of the IETF Web page: https://datatracker.ietf.org/public/ > liaison_detail.cgi?detail_id=207 > Please reply by 2006-04-17 > > From: Greg Jones(ITU-T SG 15) > To: IETF MPLS WG, CC: MFA Forum(George Swallow , > Loa Andersson ) > Cc: info@mfaforum.org > maeda@ansl.ntt.co.jp > sjtrowbridge@lucent.com > rcallon@juniper.net > fenner@research.att.com > sob@harvard.edu > sbrim@cisco.com > mpls@lists.ietf.org > Reponse Contact: tsbsg15@itu.int > Technical Contact: Ghani.Abbas@marconi.com > mark.jones@sprint.com > betts01@nortel.com > Purpose: For action > Body: We apologize for not having sent a liaison regarding three > consented Recommendations related to > T-MPLS. The intent of these Recommendations is not to change MPLS > but rather to identify a > subset of existing MPLS necessary and sufficient to provide > connection-oriented packet transport. > The approach to the work was to make a profile of the MPLS data > plane functionalities defined in > IETF RFCs using the description of MPLS provided in G.8110 (which > was approved last year). > The intended application of this profile is to provide a connection- > oriented packet transport > network. > The focus of the three new recommendations is on the data plane > aspects of T-MPLS. Control plane > aspects are currently for further study and the work on this > subject is starting. > According to our work methodology the T-MPLS definitions are split > into the three main > Recommendations that have been consented in February 2006: > * G.8110.1 dealing with the T-MPLS Architecture > * G.8112 dealing with T-MPLS interface specification > * G.8121 dealing with T-MPLS equipment functional specification > A brief high-level introduction of the essential features and > selected options for Transport MPLS > can be found in section 6/G.8110.1. > The objective of the work done by ITU-T SG15 was to define a way to > use MPLS as a connection- > oriented packet-based transport solution for packet aware transport > networks that can support both > packet and circuit (e.g. SDH, OTH or WDM) switching technologies > under a common operation, > control and management paradigm. For this purpose T-MPLS deploys > the MPLS frame format, > Client to MPLS mapping and MPLS to MPLS multiplexing and > complements this with transport > network OAM (Y.1711), nested connection monitoring requiring the > labels to be present up to the > final node in the network, protection switching (Y.1720/G.8131), > transport network based control > and management planes, maintaining frame ordering and a restricted > number of classes of > service/queues. > * MPLS has many applications and it is desirable to identify a > subset of MPLS technology that > provides the necessary and sufficient functionality for transport > applications. > We have indicated below some of the options we have selected :- > * In IETF RFCs the usage of PHP is optional. We decided not to use > it in order to simplify OAM > procedures > * In IETF RFCs the usage of merging is optional. We decided not to > use it in order to simplify > OAM procedures and also because the relative lower number of LSPs > to be supported is not > considered a major scaling issue > * The usage of ECMP is optional. We decided not to use it in order > to simplify OAM procedures > * Leaving labels 16-31 for further study was seen as a no change > because the label allocation on a > link is defined in IETF RFCs as a local matter for any MPLS device. > We are not expecting that the current version of the specification > is going to create any > interoperability issue. We envisage two possible cases of > interoperability: > 1. Interoperability between a T-MPLS box and an existing full- > featured and fully configurable > MPLS box can be solved by configuring the MPLS box to use the same > options selected by T- > MPLS (T-MPLS being a profile of MPLS this should be possible). In > this case the link between > the two boxes is a T-MPLS link and in the scope of our > Recommendations. > 2. Interoperability between a transport platform supporting T-MPLS > and an existing MPLS box > that uses a different option selection than T-MPLS, should be > solved by the transport platform. > In this case the link between the transport platform and the MPLS > box is not a T-MPLS link and > therefore it is outside the scope of T-MPLS recommendations. We are > looking for cooperation > with IETF to develop the detailed specification of this case. > Please find attached the text of the consented Recommendations. > Please note that some minor > modifications may be made to these draft Recommendations as a > result of comments made during > the approval process > We will appreciate your comments and suggestions in relation to the > initial scope of T-MPLS as a > packet transport network technology. > We are planning to review your comments during the next meeting > that is planned in Kobe (Japan) > on 22-27 April 2006. Results of the comments will be included into > our future work (e.g. corrigenda > or amendments) on T-MPLS Recommendations. Amendments of T-MPLS > Recommendations are > already in our plan for the next SG15 plenary meeting in November > 2006.We are looking forward > for future cooperation with you in T-MPLS data plane and control > plane evolution. > > Attachments: Consented Text of G.8110.1, G.8112, G.8121 > Attachment(s): > Consented Text of G.8110.1 (https://datatracker.ietf.org/ > documents/LIAISON/file288.zip) > Consented Text of G.8112 (https://datatracker.ietf.org/ > documents/LIAISON/file289.zip) > Consented Text of G.8121 (https://datatracker.ietf.org/ > documents/LIAISON/file290.zip) > > > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 10:19:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJgL-0006Gx-Li; Tue, 11 Apr 2006 10:17:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJgK-0006GM-36 for mpls@lists.ietf.org; Tue, 11 Apr 2006 10:17:24 -0400 Received: from mother.pmc-sierra.com ([216.241.224.12] helo=mother.pmc-sierra.bc.ca) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTJgJ-0003JP-Cd for mpls@lists.ietf.org; Tue, 11 Apr 2006 10:17:24 -0400 Received: (qmail 29332 invoked by uid 101); 11 Apr 2006 14:17:22 -0000 Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236) by mother.pmc-sierra.com with SMTP; 11 Apr 2006 14:17:22 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogyruan.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k3BEHLAj007497; Tue, 11 Apr 2006 07:17:21 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id <132HN07R>; Tue, 11 Apr 2006 07:17:21 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE024333B6@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> From: Shahram Davari To: "'Thomas D. Nadeau'" , mpls@lists.ietf.org Subject: RE: [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns" Date: Tue, 11 Apr 2006 07:16:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Tom, 1) Reading the T-MPLS specs I didn't see any specific label range restriction. Where have you seen this? 2) The OAM specified is for T-MPLS, which as you said is a subset of MPLS. Specifically T-MPLS doesn't include PHP, merging and ECMP as indicated by the Liaison. So why should an OAM that is going to be used for T-MPLS support those functions? Regards, -Shahram > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Tuesday, April 11, 2006 9:25 AM > To: mpls@lists.ietf.org > Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented > Recommendations" > > > [Resending to mpls list as I got a warning from the mailer > that there was a suspicious number of recipients, so I am not > sure it was delivered.] > > Hi, > > A few things in the ITU T-MPLS document concern me: > > 1) The document itself constitutes what is essentially > two things: an protocol specification > and an implementation guideline. > > For this reason, I first suggest that this document > needs to be split into two: one that specifies > the label range allocation (as well as requests > it from the IETF), and a second that specifies > the implementation guideline. I also suggest > removal of "MPLS" from the name. This is very > confusing, and implies that this document is > some new standard for MPLS, whereas what it > really specifies (sans the label range allocation > and the OAM) is a subset of MPLS functionality. > > 2) With regard to the label range reservation, I am > troubled by this because MPLS has been widely deployed > without the said reserved label range. Deployment > of LSRs that suddenly use this special label > range will most likely lead to interoperability > issues. I am also troubled by the lack of > definition of what the reserved labels should > be used for. If in the future, these labels are > defined in a manner that is incompatible with > existing LSRs, this will pose a significant > hurdle to deployments. Again, a separate document that > requests the label range, as well as specifies > what they are to be used for is appropriate. > > 3) The OAM as specified does not meet the IETF's > requirements for OAM specified in RFC4377. > Y.1711 is not suitable for environments where PHP is > enabled, and it also has other deficiencies such as a > lack of tracing functionality, and cannot handle Equal > Cost Multi-Path (ECMP) LSPs. In particular, section > 4.3 of RFC4377 stipulates that path characterization > functions must be able to work in these cases: > > 4.3. Path Characterization > > The path characterization function is the ability to > reveal details > of LSR forwarding operations. These details can then be compared > during subsequent testing relevant to OAM functionality. This > includes but is not limited to: > > - consistent use of pipe or uniform time to live > (TTL) models by > an LSR [RFC3443]. > > - sufficient details that allow the test origin to > exercise all > path permutations related to load spreading (e.g., ECMP). > > - stack operations performed by the LSR, such as pushes, pops, > and TTL propagation at penultimate hop LSRs. > > I suggest replacing the reference to Y.1711 with a reference > to rfc4377, rfc4378, and rfc4379. > > --Tom > > > > > Title: T-MPLS Consented Recommendations > > Submission Date: 2006-04-02 > > URL of the IETF Web page: https://datatracker.ietf.org/public/ > > liaison_detail.cgi?detail_id=207 > > Please reply by 2006-04-17 > > > > From: Greg Jones(ITU-T SG 15) > > To: IETF MPLS WG, CC: MFA Forum(George Swallow > , > > Loa Andersson ) > > Cc: info@mfaforum.org > > maeda@ansl.ntt.co.jp > > sjtrowbridge@lucent.com > > rcallon@juniper.net > > fenner@research.att.com > > sob@harvard.edu > > sbrim@cisco.com > > mpls@lists.ietf.org > > Reponse Contact: tsbsg15@itu.int > > Technical Contact: Ghani.Abbas@marconi.com > > mark.jones@sprint.com > > betts01@nortel.com > > Purpose: For action > > Body: We apologize for not having sent a liaison regarding three > > consented Recommendations related to > > T-MPLS. The intent of these Recommendations is not to change MPLS > > but rather to identify a > > subset of existing MPLS necessary and sufficient to provide > > connection-oriented packet transport. > > The approach to the work was to make a profile of the MPLS data > > plane functionalities defined in > > IETF RFCs using the description of MPLS provided in G.8110 (which > > was approved last year). > > The intended application of this profile is to provide a > connection- > > oriented packet transport > > network. > > The focus of the three new recommendations is on the data plane > > aspects of T-MPLS. Control plane > > aspects are currently for further study and the work on this > > subject is starting. > > According to our work methodology the T-MPLS definitions are split > > into the three main > > Recommendations that have been consented in February 2006: > > * G.8110.1 dealing with the T-MPLS Architecture > > * G.8112 dealing with T-MPLS interface specification > > * G.8121 dealing with T-MPLS equipment functional specification > > A brief high-level introduction of the essential features and > > selected options for Transport MPLS > > can be found in section 6/G.8110.1. > > The objective of the work done by ITU-T SG15 was to define > a way to > > use MPLS as a connection- > > oriented packet-based transport solution for packet aware > transport > > networks that can support both > > packet and circuit (e.g. SDH, OTH or WDM) switching technologies > > under a common operation, > > control and management paradigm. For this purpose T-MPLS deploys > > the MPLS frame format, > > Client to MPLS mapping and MPLS to MPLS multiplexing and > > complements this with transport > > network OAM (Y.1711), nested connection monitoring requiring the > > labels to be present up to the > > final node in the network, protection switching (Y.1720/G.8131), > > transport network based control > > and management planes, maintaining frame ordering and a restricted > > number of classes of > > service/queues. > > * MPLS has many applications and it is desirable to identify a > > subset of MPLS technology that > > provides the necessary and sufficient functionality for transport > > applications. > > We have indicated below some of the options we have selected :- > > * In IETF RFCs the usage of PHP is optional. We decided > not to use > > it in order to simplify OAM > > procedures > > * In IETF RFCs the usage of merging is optional. We > decided not to > > use it in order to simplify > > OAM procedures and also because the relative lower number of LSPs > > to be supported is not > > considered a major scaling issue > > * The usage of ECMP is optional. We decided not to use it > in order > > to simplify OAM procedures > > * Leaving labels 16-31 for further study was seen as a no change > > because the label allocation on a > > link is defined in IETF RFCs as a local matter for any MPLS device. > > We are not expecting that the current version of the specification > > is going to create any > > interoperability issue. We envisage two possible cases of > > interoperability: > > 1. Interoperability between a T-MPLS box and an existing full- > > featured and fully configurable > > MPLS box can be solved by configuring the MPLS box to use the same > > options selected by T- > > MPLS (T-MPLS being a profile of MPLS this should be possible). In > > this case the link between > > the two boxes is a T-MPLS link and in the scope of our > > Recommendations. > > 2. Interoperability between a transport platform > supporting T-MPLS > > and an existing MPLS box > > that uses a different option selection than T-MPLS, should be > > solved by the transport platform. > > In this case the link between the transport platform and the MPLS > > box is not a T-MPLS link and > > therefore it is outside the scope of T-MPLS > recommendations. We are > > looking for cooperation > > with IETF to develop the detailed specification of this case. > > Please find attached the text of the consented Recommendations. > > Please note that some minor > > modifications may be made to these draft Recommendations as a > > result of comments made during > > the approval process > > We will appreciate your comments and suggestions in > relation to the > > initial scope of T-MPLS as a > > packet transport network technology. > > We are planning to review your comments during the next meeting > > that is planned in Kobe (Japan) > > on 22-27 April 2006. Results of the comments will be included into > > our future work (e.g. corrigenda > > or amendments) on T-MPLS Recommendations. Amendments of T-MPLS > > Recommendations are > > already in our plan for the next SG15 plenary meeting in November > > 2006.We are looking forward > > for future cooperation with you in T-MPLS data plane and control > > plane evolution. > > > > Attachments: Consented Text of G.8110.1, G.8112, G.8121 > > Attachment(s): > > Consented Text of G.8110.1 (https://datatracker.ietf.org/ > > documents/LIAISON/file288.zip) > > Consented Text of G.8112 (https://datatracker.ietf.org/ > > documents/LIAISON/file289.zip) > > Consented Text of G.8121 (https://datatracker.ietf.org/ > > documents/LIAISON/file290.zip) > > > > > > > > > > _______________________________________________ > > 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@lists.ietf.org Tue Apr 11 10:25:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJmI-0007rC-OL; Tue, 11 Apr 2006 10:23:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJmG-0007r5-Ot for mpls@ietf.org; Tue, 11 Apr 2006 10:23:32 -0400 Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTJmG-0003XE-HW for mpls@ietf.org; Tue, 11 Apr 2006 10:23:32 -0400 Received: from user-2ivf947.dsl.mindspring.com ([165.247.164.135] helo=JMHLap3.stevecrocker.com) by pop-scotia.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1FTJm8-0001rd-00; Tue, 11 Apr 2006 10:23:25 -0400 Message-Id: <7.0.1.0.0.20060411101634.03689c90@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 11 Apr 2006 10:22:53 -0400 To: "Dutta, Pranjal" From: "Joel M. Halpern" Subject: Re: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs In-Reply-To: <443B8CA8.50806@netscape.net> References: <443B8CA8.50806@netscape.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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: , Errors-To: mpls-bounces@lists.ietf.org I think that there may be a better way to explain this. There are several different factors at work: 1) A received LDP label MUST NOT be used if the neighbor sending the label is not the next hop for the FEC. This condition does not require an exact match in the forwarding table. 2) A Received label MUST NOT be used for packets which do not match the received FEC. This condition requires an exact match in the forwarding table. This does allow an implementation to create an exact match entry in the forwarding table to select packets that use the label, even if routing provided a shorter prefix. This does allow one to use /32 entries without injecting those /32s into the actual routing protocol. However, the most common uses of .LDP (even with /32s) will result in the entries being in the forwarding table anyway. Another way to look at the condition above is that condition 1 is a restriction on the use of a received label advertisement. LPM check is suitable. Condition 2 is a restriction on the contents of the Forwarding-Table-to-Next-hop-label-forwarding-entry that one creates. That must be an exact match. Yours, Joel M. Halpern At 07:02 AM 4/11/2006, Eric W Gray wrote: >The implementation MUST do an exact match, as downstream LSRs will >forward based >only on the label. Because they do not (typically) perform a route >look-up on the label >encapsulated inner IP packet, there is no reason to expect a >downstream LSR to be able >to separate a flow based on longest match when the routes further >downstream are distinct >for "longer matches". > >Dutta, Pranjal wrote: > >> >>Hi Eric, >> As per RFC 3036 Label mapping receive procedures, when Ru >>received a label mapping from Rd for a FEC x, Ru need to find an "exact" >>match of the FEC x(IPv4/V6 prefix) in its route table. In Inter-IGP-area >>or inter-AS case the routes from Rd would be summarized to Ru and in >>such a case Ru MAY not find the exact match for such FEC x. In terms of >>RFC 3036 then Ru MAY not find exact match for the FEC received from Rd >>in its route table and no further action at Ru. My question was why Ru >>can't we do a longest prefix match for the FEC x as LPM means it can be >>reached by a downstream Rd? >> >>Thanks, >>Pranjal > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 10:31:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJp8-0002vD-Gl; Tue, 11 Apr 2006 10:26:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJp7-0002v8-OE for mpls@lists.ietf.org; Tue, 11 Apr 2006 10:26:29 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTJp7-0003i6-0L for mpls@lists.ietf.org; Tue, 11 Apr 2006 10:26:29 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 15:26:26 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 15:26:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] New Liaison Statement, "T-MPLS Consented Recommendations" Date: Tue, 11 Apr 2006 15:26:25 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353891576C7E5@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] New Liaison Statement, "T-MPLS Consented Recommendations" Thread-Index: AcZdV9QlDRxs+cwsQgmyoL9QhIZ9kwAFhUSAAAFTR4A= From: To: X-OriginalArrivalTime: 11 Apr 2006 14:26:25.0899 (UTC) FILETIME=[EA3AEBB0:01C65D73] X-Spam-Score: 0.2 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Cc: mpls@lists.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: , Errors-To: mpls-bounces@lists.ietf.org I too got a mail-fail indicate on this ('too many recipients') so re-posting just to the MPLS folks. =20 > Tom, >=20 > A couple of observations on your remarks: >=20 > (i) I agree with you that some clarity is required on=20 > specific reserved label ranges and their uses. However, I'd=20 > say it's bigger than just the label ranges and should also=20 > include how all the header fields (ie S, EXP, TTL) are to be=20 > used in T-MPLS (I noted you don't think this 'T-MPLS' name is=20 > good, but I'll stick with it here). Why? Well, folks need=20 > to consider the various client/server relationships that=20 > could exist between the various spins of MPLS as-is and=20 > T-MPLS....and especially misconnectivity between them....so=20 > how is this going to be handled? >=20 > (ii) I'd urge you not to be so hard on Y.1711. This is a=20 > simple defect detection/handling OAM solution for ANY co-ps=20 > mode network based on label-swapping that respects the=20 > architectural requirement of what defines a connection (ie=20 > single source, connectivity=3D1). Any form of MPLS that has=20 > merging (so that is LDP and/or PHP) violates the rules for a=20 > connection.....this is just a fact.....and so Y.1711 is not=20 > appropriate (but then attempting to apply any sort of=20 > determinism across any aspect of traffic/fault/performance=20 > management is fraught with problems when the rules for=20 > connections are broken). >=20 > regards, Neil >=20 > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: 10 April 2006 16:15 > > To: Greg Jones(ITU-T SG 15) > > Cc: mpls@lists.ietf.org; mark.jones@sprint.com;=20 > > maeda@ansl.ntt.co.jp; info@mfaforum.org;=20 > > Ghani.Abbas@marconi.com; Scott Brim W; Bill (E-mail) Fenner;=20 > > statements@ietf.org; Ross Callon; betts01@nortel.com > > Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented=20 > > Recommendations"=20 > >=20 > >=20 > >=20 > > Hi, > >=20 > > A few things in the ITU T-MPLS document concern me: > >=20 > > 1) The document itself constitutes what is essentially > > two things: an protocol specification > > and an implementation guideline. > >=20 > > For this reason, I first suggest that this document > > needs to be split into two: one that specifies > > the label range allocation (as well as requests > > it from the IETF), and a second that specifies > > the implementation guideline. I also suggest > > removal of "MPLS" from the name. This is very > > confusing, and implies that this document is > > some new standard for MPLS, whereas what it > > really specifies (sans the label range allocation > > and the OAM) is a subset of MPLS functionality. > >=20 > > 2) With regard to the label range reservation, I am > > troubled by this because MPLS has been widely deployed > > without the said reserved label range. Deployment > > of LSRs that suddenly use this special label > > range will most likely lead to interoperability > > issues. I am also troubled by the lack of > > definition of what the reserved labels should > > be used for. If in the future, these labels are > > defined in a manner that is incompatible with > > existing LSRs, this will pose a significant > > hurdle to deployments. Again, a separate document that > > requests the label range, as well as specifies > > what they are to be used for is appropriate. > >=20 > > 3) The OAM as specified does not meet the IETF's > > requirements for OAM specified in RFC4377. > > Y.1711 is not suitable for environments where PHP is > > enabled, and it also has other deficiencies such as a > > lack of tracing functionality, and cannot handle Equal > > Cost Multi-Path (ECMP) LSPs. In particular, section > > 4.3 of RFC4377 stipulates that path characterization > > functions must be able to work in these cases: > >=20 > > 4.3. Path Characterization > >=20 > > The path characterization function is the ability to > > reveal details > > of LSR forwarding operations. These details can then=20 > be compared > > during subsequent testing relevant to OAM functionality. This > > includes but is not limited to: > >=20 > > - consistent use of pipe or uniform time to live > > (TTL) models by > > an LSR [RFC3443]. > >=20 > > - sufficient details that allow the test origin to > > exercise all > > path permutations related to load spreading (e.g., ECMP). > >=20 > > - stack operations performed by the LSR, such as=20 > pushes, pops, > > and TTL propagation at penultimate hop LSRs. > >=20 > > I suggest replacing the reference to Y.1711 with a reference > > to rfc4377, rfc4378, and rfc4379. > >=20 > > --Tom > >=20 > >=20 > >=20 > > > Title: T-MPLS Consented Recommendations > > > Submission Date: 2006-04-02 > > > URL of the IETF Web page: https://datatracker.ietf.org/public/ > > > liaison_detail.cgi?detail_id=3D207 > > > Please reply by 2006-04-17 > > > > > > From: Greg Jones(ITU-T SG 15) > > > To: IETF MPLS WG, CC: MFA Forum(George Swallow=20 > ,=20 > > > Loa Andersson ) > > > Cc: info@mfaforum.org > > > maeda@ansl.ntt.co.jp > > > sjtrowbridge@lucent.com > > > rcallon@juniper.net > > > fenner@research.att.com > > > sob@harvard.edu > > > sbrim@cisco.com > > > mpls@lists.ietf.org > > > Reponse Contact: tsbsg15@itu.int > > > Technical Contact: Ghani.Abbas@marconi.com mark.jones@sprint.com > > > betts01@nortel.com > > > Purpose: For action > > > Body: We apologize for not having sent a liaison regarding three =20 > > > consented Recommendations related to > > > T-MPLS. The intent of these Recommendations is not to=20 > change MPLS =20 > > > but rather to identify a > > > subset of existing MPLS necessary and sufficient to provide =20 > > > connection-oriented packet transport. > > > The approach to the work was to make a profile of the MPLS data =20 > > > plane functionalities defined in > > > IETF RFCs using the description of MPLS provided in=20 > G.8110 (which =20 > > > was approved last year). > > > The intended application of this profile is to provide a=20 > > connection- > > > oriented packet transport > > > network. > > > The focus of the three new recommendations is on the data plane > > > aspects of T-MPLS. Control plane > > > aspects are currently for further study and the work on this =20 > > > subject is starting. > > > According to our work methodology the T-MPLS definitions=20 > are split =20 > > > into the three main > > > Recommendations that have been consented in February 2006: > > > * G.8110.1 dealing with the T-MPLS Architecture > > > * G.8112 dealing with T-MPLS interface specification > > > * G.8121 dealing with T-MPLS equipment functional specification > > > A brief high-level introduction of the essential features and =20 > > > selected options for Transport MPLS > > > can be found in section 6/G.8110.1. > > > The objective of the work done by ITU-T SG15 was to define=20 > > a way to > > > use MPLS as a connection- > > > oriented packet-based transport solution for packet aware > > transport > > > networks that can support both > > > packet and circuit (e.g. SDH, OTH or WDM) switching technologies > > > under a common operation, > > > control and management paradigm. For this purpose T-MPLS deploys =20 > > > the MPLS frame format, > > > Client to MPLS mapping and MPLS to MPLS multiplexing and =20 > > > complements this with transport > > > network OAM (Y.1711), nested connection monitoring requiring the =20 > > > labels to be present up to the > > > final node in the network, protection switching (Y.1720/G.8131), =20 > > > transport network based control > > > and management planes, maintaining frame ordering and a=20 > restricted =20 > > > number of classes of > > > service/queues. > > > * MPLS has many applications and it is desirable to identify a =20 > > > subset of MPLS technology that > > > provides the necessary and sufficient functionality for=20 > transport =20 > > > applications. > > > We have indicated below some of the options we have selected :- > > > * In IETF RFCs the usage of PHP is optional. We decided=20 > > not to use > > > it in order to simplify OAM > > > procedures > > > * In IETF RFCs the usage of merging is optional. We=20 > > decided not to > > > use it in order to simplify > > > OAM procedures and also because the relative lower number of LSPs > > > to be supported is not > > > considered a major scaling issue > > > * The usage of ECMP is optional. We decided not to use it=20 > > in order > > > to simplify OAM procedures > > > * Leaving labels 16-31 for further study was seen as a no change =20 > > > because the label allocation on a > > > link is defined in IETF RFCs as a local matter for any=20 > MPLS device.=20 > > > We are not expecting that the current version of the specification > > > is going to create any > > > interoperability issue. We envisage two possible cases of =20 > > > interoperability: > > > 1. Interoperability between a T-MPLS box and an=20 > existing full-=20 > > > featured and fully configurable > > > MPLS box can be solved by configuring the MPLS box to use=20 > the same =20 > > > options selected by T- > > > MPLS (T-MPLS being a profile of MPLS this should be=20 > possible). In =20 > > > this case the link between > > > the two boxes is a T-MPLS link and in the scope of our =20 > > > Recommendations. > > > 2. Interoperability between a transport platform=20 > > supporting T-MPLS > > > and an existing MPLS box > > > that uses a different option selection than T-MPLS, should be > > > solved by the transport platform. > > > In this case the link between the transport platform and=20 > the MPLS =20 > > > box is not a T-MPLS link and > > > therefore it is outside the scope of T-MPLS=20 > > recommendations. We are > > > looking for cooperation > > > with IETF to develop the detailed specification of this case. > > > Please find attached the text of the consented Recommendations. =20 > > > Please note that some minor > > > modifications may be made to these draft Recommendations as a > > > result of comments made during > > > the approval process > > > We will appreciate your comments and suggestions in=20 > > relation to the > > > initial scope of T-MPLS as a > > > packet transport network technology. > > > We are planning to review your comments during the next meeting > > > that is planned in Kobe (Japan) > > > on 22-27 April 2006. Results of the comments will be=20 > included into =20 > > > our future work (e.g. corrigenda > > > or amendments) on T-MPLS Recommendations. Amendments of T-MPLS =20 > > > Recommendations are > > > already in our plan for the next SG15 plenary meeting in=20 > November =20 > > > 2006.We are looking forward > > > for future cooperation with you in T-MPLS data plane and control =20 > > > plane evolution. > > > > > > Attachments: Consented Text of G.8110.1, G.8112, G.8121 > > > Attachment(s): > > > Consented Text of G.8110.1 (https://datatracker.ietf.org/ > > > documents/LIAISON/file288.zip) > > > Consented Text of G.8112 (https://datatracker.ietf.org/ > > > documents/LIAISON/file289.zip) > > > Consented Text of G.8121 (https://datatracker.ietf.org/=20 > > > documents/LIAISON/file290.zip) > > > > > > > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls > >=20 > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls > >=20 >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 10:36:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJwr-0005Ve-8g; Tue, 11 Apr 2006 10:34:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJwq-0005VZ-CG for mpls@lists.ietf.org; Tue, 11 Apr 2006 10:34:28 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTJwp-00040h-Ne for mpls@lists.ietf.org; Tue, 11 Apr 2006 10:34:28 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 11 Apr 2006 07:34:27 -0700 X-IronPort-AV: i="4.04,112,1144047600"; d="scan'208"; a="1793852638:sNHT36643516" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k3BEYQYg010489; Tue, 11 Apr 2006 07:34:26 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 10:34:26 -0400 Received: from [10.83.15.57] ([10.83.15.57]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 10:34:25 -0400 In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE024333B6@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> References: <4B6D09F3B826D411A67300D0B706EFDE024333B6@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns" Date: Tue, 11 Apr 2006 10:34:25 -0400 To: Shahram Davari X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 11 Apr 2006 14:34:25.0611 (UTC) FILETIME=[082929B0:01C65D75] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: mpls@lists.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: , Errors-To: mpls-bounces@lists.ietf.org > Hi Tom, > > 1) Reading the T-MPLS specs I didn't see any specific label range > restriction. Where have you seen this? See inline marked with "TOM:" > 2) The OAM specified is for T-MPLS, which as you said is a subset > of MPLS. Specifically T-MPLS doesn't include PHP, merging and ECMP > as indicated by the Liaison. So why should an OAM that is going to > be used for T-MPLS support those functions? The OAM as specified in the T-MPLS document is not a subset of MPLS; it is a completely different mechanism from what is specified at the IETF to meet the requirements in RFC4377. As described, y1711 acts on a sub-set of MPLS (lets forget about the label range), but does not meet all of the requirements as specified in RFC4377, even for this subset of MPLS. --Tom > > > Regards, > -Shahram > >> -----Original Message----- >> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >> Sent: Tuesday, April 11, 2006 9:25 AM >> To: mpls@lists.ietf.org >> Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented >> Recommendations" >> >> >> [Resending to mpls list as I got a warning from the mailer >> that there was a suspicious number of recipients, so I am not >> sure it was delivered.] >> >> Hi, >> >> A few things in the ITU T-MPLS document concern me: >> >> 1) The document itself constitutes what is essentially >> two things: an protocol specification >> and an implementation guideline. >> >> For this reason, I first suggest that this document >> needs to be split into two: one that specifies >> the label range allocation (as well as requests >> it from the IETF), and a second that specifies >> the implementation guideline. I also suggest >> removal of "MPLS" from the name. This is very >> confusing, and implies that this document is >> some new standard for MPLS, whereas what it >> really specifies (sans the label range allocation >> and the OAM) is a subset of MPLS functionality. >> >> 2) With regard to the label range reservation, I am >> troubled by this because MPLS has been widely deployed >> without the said reserved label range. Deployment >> of LSRs that suddenly use this special label >> range will most likely lead to interoperability >> issues. I am also troubled by the lack of >> definition of what the reserved labels should >> be used for. If in the future, these labels are >> defined in a manner that is incompatible with >> existing LSRs, this will pose a significant >> hurdle to deployments. Again, a separate document that >> requests the label range, as well as specifies >> what they are to be used for is appropriate. >> >> 3) The OAM as specified does not meet the IETF's >> requirements for OAM specified in RFC4377. >> Y.1711 is not suitable for environments where PHP is >> enabled, and it also has other deficiencies such as a >> lack of tracing functionality, and cannot handle Equal >> Cost Multi-Path (ECMP) LSPs. In particular, section >> 4.3 of RFC4377 stipulates that path characterization >> functions must be able to work in these cases: >> >> 4.3. Path Characterization >> >> The path characterization function is the ability to >> reveal details >> of LSR forwarding operations. These details can then be compared >> during subsequent testing relevant to OAM functionality. This >> includes but is not limited to: >> >> - consistent use of pipe or uniform time to live >> (TTL) models by >> an LSR [RFC3443]. >> >> - sufficient details that allow the test origin to >> exercise all >> path permutations related to load spreading (e.g., ECMP). >> >> - stack operations performed by the LSR, such as pushes, >> pops, >> and TTL propagation at penultimate hop LSRs. >> >> I suggest replacing the reference to Y.1711 with a reference >> to rfc4377, rfc4378, and rfc4379. >> >> --Tom >> >> >> >>> Title: T-MPLS Consented Recommendations >>> Submission Date: 2006-04-02 >>> URL of the IETF Web page: https://datatracker.ietf.org/public/ >>> liaison_detail.cgi?detail_id=207 >>> Please reply by 2006-04-17 >>> >>> From: Greg Jones(ITU-T SG 15) >>> To: IETF MPLS WG, CC: MFA Forum(George Swallow >> , >>> Loa Andersson ) >>> Cc: info@mfaforum.org >>> maeda@ansl.ntt.co.jp >>> sjtrowbridge@lucent.com >>> rcallon@juniper.net >>> fenner@research.att.com >>> sob@harvard.edu >>> sbrim@cisco.com >>> mpls@lists.ietf.org >>> Reponse Contact: tsbsg15@itu.int >>> Technical Contact: Ghani.Abbas@marconi.com >>> mark.jones@sprint.com >>> betts01@nortel.com >>> Purpose: For action >>> Body: We apologize for not having sent a liaison regarding three >>> consented Recommendations related to >>> T-MPLS. The intent of these Recommendations is not to change MPLS >>> but rather to identify a >>> subset of existing MPLS necessary and sufficient to provide >>> connection-oriented packet transport. >>> The approach to the work was to make a profile of the MPLS data >>> plane functionalities defined in >>> IETF RFCs using the description of MPLS provided in G.8110 (which >>> was approved last year). >>> The intended application of this profile is to provide a >> connection- >>> oriented packet transport >>> network. >>> The focus of the three new recommendations is on the data plane >>> aspects of T-MPLS. Control plane >>> aspects are currently for further study and the work on this >>> subject is starting. >>> According to our work methodology the T-MPLS definitions are split >>> into the three main >>> Recommendations that have been consented in February 2006: >>> * G.8110.1 dealing with the T-MPLS Architecture >>> * G.8112 dealing with T-MPLS interface specification >>> * G.8121 dealing with T-MPLS equipment functional specification >>> A brief high-level introduction of the essential features and >>> selected options for Transport MPLS >>> can be found in section 6/G.8110.1. >>> The objective of the work done by ITU-T SG15 was to define >> a way to >>> use MPLS as a connection- >>> oriented packet-based transport solution for packet aware >> transport >>> networks that can support both >>> packet and circuit (e.g. SDH, OTH or WDM) switching technologies >>> under a common operation, >>> control and management paradigm. For this purpose T-MPLS deploys >>> the MPLS frame format, >>> Client to MPLS mapping and MPLS to MPLS multiplexing and >>> complements this with transport >>> network OAM (Y.1711), nested connection monitoring requiring the >>> labels to be present up to the >>> final node in the network, protection switching (Y.1720/G.8131), >>> transport network based control >>> and management planes, maintaining frame ordering and a restricted >>> number of classes of >>> service/queues. >>> * MPLS has many applications and it is desirable to identify a >>> subset of MPLS technology that >>> provides the necessary and sufficient functionality for transport >>> applications. >>> We have indicated below some of the options we have selected :- >>> * In IETF RFCs the usage of PHP is optional. We decided >> not to use >>> it in order to simplify OAM >>> procedures >>> * In IETF RFCs the usage of merging is optional. We >> decided not to >>> use it in order to simplify >>> OAM procedures and also because the relative lower number of LSPs >>> to be supported is not >>> considered a major scaling issue >>> * The usage of ECMP is optional. We decided not to use it >> in order >>> to simplify OAM procedures >>> * Leaving labels 16-31 for further study was seen as a no change >>> because the label allocation on a TOM: Read above. >>> link is defined in IETF RFCs as a local matter for any MPLS device. >>> We are not expecting that the current version of the specification >>> is going to create any >>> interoperability issue. We envisage two possible cases of >>> interoperability: >>> 1. Interoperability between a T-MPLS box and an existing full- >>> featured and fully configurable >>> MPLS box can be solved by configuring the MPLS box to use the same >>> options selected by T- >>> MPLS (T-MPLS being a profile of MPLS this should be possible). In >>> this case the link between >>> the two boxes is a T-MPLS link and in the scope of our >>> Recommendations. >>> 2. Interoperability between a transport platform >> supporting T-MPLS >>> and an existing MPLS box >>> that uses a different option selection than T-MPLS, should be >>> solved by the transport platform. >>> In this case the link between the transport platform and the MPLS >>> box is not a T-MPLS link and >>> therefore it is outside the scope of T-MPLS >> recommendations. We are >>> looking for cooperation >>> with IETF to develop the detailed specification of this case. >>> Please find attached the text of the consented Recommendations. >>> Please note that some minor >>> modifications may be made to these draft Recommendations as a >>> result of comments made during >>> the approval process >>> We will appreciate your comments and suggestions in >> relation to the >>> initial scope of T-MPLS as a >>> packet transport network technology. >>> We are planning to review your comments during the next meeting >>> that is planned in Kobe (Japan) >>> on 22-27 April 2006. Results of the comments will be included into >>> our future work (e.g. corrigenda >>> or amendments) on T-MPLS Recommendations. Amendments of T-MPLS >>> Recommendations are >>> already in our plan for the next SG15 plenary meeting in November >>> 2006.We are looking forward >>> for future cooperation with you in T-MPLS data plane and control >>> plane evolution. >>> >>> Attachments: Consented Text of G.8110.1, G.8112, G.8121 >>> Attachment(s): >>> Consented Text of G.8110.1 (https://datatracker.ietf.org/ >>> documents/LIAISON/file288.zip) >>> Consented Text of G.8112 (https://datatracker.ietf.org/ >>> documents/LIAISON/file289.zip) >>> Consented Text of G.8121 (https://datatracker.ietf.org/ >>> documents/LIAISON/file290.zip) >>> >>> >>> >>> >>> _______________________________________________ >>> 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 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 10:45:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTK6A-00012v-IB; Tue, 11 Apr 2006 10:44:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTK69-00012q-2N for mpls@lists.ietf.org; Tue, 11 Apr 2006 10:44:05 -0400 Received: from father.pmc-sierra.com ([216.241.224.13] helo=father.pmc-sierra.bc.ca) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTK68-0004Ep-9Q for mpls@lists.ietf.org; Tue, 11 Apr 2006 10:44:05 -0400 Received: (qmail 14178 invoked by uid 101); 11 Apr 2006 14:44:03 -0000 Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59) by father.pmc-sierra.com with SMTP; 11 Apr 2006 14:44:03 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogmios.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k3BEi2hn017895; Tue, 11 Apr 2006 07:44:03 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id <132H3BWC>; Tue, 11 Apr 2006 07:44:02 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE024333B9@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> From: Shahram Davari To: "'Thomas D. Nadeau'" Subject: RE: [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns" Date: Tue, 11 Apr 2006 07:43:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Cc: mpls@lists.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: , Errors-To: mpls-bounces@lists.ietf.org Why do you think T-MPLS is a completely different mechanism than MPLS? Also why should the OAM for T-MPLS that is not using PHP, ECMP and merging satisfy the general OAM requirements as specified in RFC4377? -Shahram > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Tuesday, April 11, 2006 10:34 AM > To: Shahram Davari > Cc: mpls@lists.ietf.org > Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented > Recommendatio ns" > > > > > Hi Tom, > > > > 1) Reading the T-MPLS specs I didn't see any specific label range > > restriction. Where have you seen this? > > See inline marked with "TOM:" > > > 2) The OAM specified is for T-MPLS, which as you said is a subset > > of MPLS. Specifically T-MPLS doesn't include PHP, merging and ECMP > > as indicated by the Liaison. So why should an OAM that is going to > > be used for T-MPLS support those functions? > > The OAM as specified in the T-MPLS document is not a subset of > MPLS; it is a completely different mechanism from what is specified > at the IETF to meet the requirements in RFC4377. As described, y1711 > acts on a sub-set of MPLS (lets forget about the label range), but > does not meet all of the requirements as specified in RFC4377, > even for this subset of MPLS. > > --Tom > > > > > > > > > Regards, > > -Shahram > > > >> -----Original Message----- > >> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >> Sent: Tuesday, April 11, 2006 9:25 AM > >> To: mpls@lists.ietf.org > >> Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented > >> Recommendations" > >> > >> > >> [Resending to mpls list as I got a warning from the mailer > >> that there was a suspicious number of recipients, so I am not > >> sure it was delivered.] > >> > >> Hi, > >> > >> A few things in the ITU T-MPLS document concern me: > >> > >> 1) The document itself constitutes what is essentially > >> two things: an protocol specification > >> and an implementation guideline. > >> > >> For this reason, I first suggest that this document > >> needs to be split into two: one that specifies > >> the label range allocation (as well as requests > >> it from the IETF), and a second that specifies > >> the implementation guideline. I also suggest > >> removal of "MPLS" from the name. This is very > >> confusing, and implies that this document is > >> some new standard for MPLS, whereas what it > >> really specifies (sans the label range allocation > >> and the OAM) is a subset of MPLS functionality. > >> > >> 2) With regard to the label range reservation, I am > >> troubled by this because MPLS has been widely deployed > >> without the said reserved label range. Deployment > >> of LSRs that suddenly use this special label > >> range will most likely lead to interoperability > >> issues. I am also troubled by the lack of > >> definition of what the reserved labels should > >> be used for. If in the future, these labels are > >> defined in a manner that is incompatible with > >> existing LSRs, this will pose a significant > >> hurdle to deployments. Again, a separate document that > >> requests the label range, as well as specifies > >> what they are to be used for is appropriate. > >> > >> 3) The OAM as specified does not meet the IETF's > >> requirements for OAM specified in RFC4377. > >> Y.1711 is not suitable for environments where PHP is > >> enabled, and it also has other deficiencies such as a > >> lack of tracing functionality, and cannot handle Equal > >> Cost Multi-Path (ECMP) LSPs. In particular, section > >> 4.3 of RFC4377 stipulates that path characterization > >> functions must be able to work in these cases: > >> > >> 4.3. Path Characterization > >> > >> The path characterization function is the ability to > >> reveal details > >> of LSR forwarding operations. These details can then > be compared > >> during subsequent testing relevant to OAM functionality. This > >> includes but is not limited to: > >> > >> - consistent use of pipe or uniform time to live > >> (TTL) models by > >> an LSR [RFC3443]. > >> > >> - sufficient details that allow the test origin to > >> exercise all > >> path permutations related to load spreading (e.g., ECMP). > >> > >> - stack operations performed by the LSR, such as pushes, > >> pops, > >> and TTL propagation at penultimate hop LSRs. > >> > >> I suggest replacing the reference to Y.1711 with a reference > >> to rfc4377, rfc4378, and rfc4379. > >> > >> --Tom > >> > >> > >> > >>> Title: T-MPLS Consented Recommendations > >>> Submission Date: 2006-04-02 > >>> URL of the IETF Web page: https://datatracker.ietf.org/public/ > >>> liaison_detail.cgi?detail_id=207 > >>> Please reply by 2006-04-17 > >>> > >>> From: Greg Jones(ITU-T SG 15) > >>> To: IETF MPLS WG, CC: MFA Forum(George Swallow > >> , > >>> Loa Andersson ) > >>> Cc: info@mfaforum.org > >>> maeda@ansl.ntt.co.jp > >>> sjtrowbridge@lucent.com > >>> rcallon@juniper.net > >>> fenner@research.att.com > >>> sob@harvard.edu > >>> sbrim@cisco.com > >>> mpls@lists.ietf.org > >>> Reponse Contact: tsbsg15@itu.int > >>> Technical Contact: Ghani.Abbas@marconi.com > >>> mark.jones@sprint.com > >>> betts01@nortel.com > >>> Purpose: For action > >>> Body: We apologize for not having sent a liaison regarding three > >>> consented Recommendations related to > >>> T-MPLS. The intent of these Recommendations is not to change MPLS > >>> but rather to identify a > >>> subset of existing MPLS necessary and sufficient to provide > >>> connection-oriented packet transport. > >>> The approach to the work was to make a profile of the MPLS data > >>> plane functionalities defined in > >>> IETF RFCs using the description of MPLS provided in G.8110 (which > >>> was approved last year). > >>> The intended application of this profile is to provide a > >> connection- > >>> oriented packet transport > >>> network. > >>> The focus of the three new recommendations is on the data plane > >>> aspects of T-MPLS. Control plane > >>> aspects are currently for further study and the work on this > >>> subject is starting. > >>> According to our work methodology the T-MPLS definitions are split > >>> into the three main > >>> Recommendations that have been consented in February 2006: > >>> * G.8110.1 dealing with the T-MPLS Architecture > >>> * G.8112 dealing with T-MPLS interface specification > >>> * G.8121 dealing with T-MPLS equipment functional specification > >>> A brief high-level introduction of the essential features and > >>> selected options for Transport MPLS > >>> can be found in section 6/G.8110.1. > >>> The objective of the work done by ITU-T SG15 was to define > >> a way to > >>> use MPLS as a connection- > >>> oriented packet-based transport solution for packet aware > >> transport > >>> networks that can support both > >>> packet and circuit (e.g. SDH, OTH or WDM) switching technologies > >>> under a common operation, > >>> control and management paradigm. For this purpose T-MPLS deploys > >>> the MPLS frame format, > >>> Client to MPLS mapping and MPLS to MPLS multiplexing and > >>> complements this with transport > >>> network OAM (Y.1711), nested connection monitoring requiring the > >>> labels to be present up to the > >>> final node in the network, protection switching (Y.1720/G.8131), > >>> transport network based control > >>> and management planes, maintaining frame ordering and a restricted > >>> number of classes of > >>> service/queues. > >>> * MPLS has many applications and it is desirable to identify a > >>> subset of MPLS technology that > >>> provides the necessary and sufficient functionality for transport > >>> applications. > >>> We have indicated below some of the options we have selected :- > >>> * In IETF RFCs the usage of PHP is optional. We decided > >> not to use > >>> it in order to simplify OAM > >>> procedures > >>> * In IETF RFCs the usage of merging is optional. We > >> decided not to > >>> use it in order to simplify > >>> OAM procedures and also because the relative lower number of LSPs > >>> to be supported is not > >>> considered a major scaling issue > >>> * The usage of ECMP is optional. We decided not to use it > >> in order > >>> to simplify OAM procedures > >>> * Leaving labels 16-31 for further study was seen as a no change > >>> because the label allocation on a > > TOM: Read above. > > >>> link is defined in IETF RFCs as a local matter for any > MPLS device. > >>> We are not expecting that the current version of the specification > >>> is going to create any > >>> interoperability issue. We envisage two possible cases of > >>> interoperability: > >>> 1. Interoperability between a T-MPLS box and an > existing full- > >>> featured and fully configurable > >>> MPLS box can be solved by configuring the MPLS box to use the same > >>> options selected by T- > >>> MPLS (T-MPLS being a profile of MPLS this should be possible). In > >>> this case the link between > >>> the two boxes is a T-MPLS link and in the scope of our > >>> Recommendations. > >>> 2. Interoperability between a transport platform > >> supporting T-MPLS > >>> and an existing MPLS box > >>> that uses a different option selection than T-MPLS, should be > >>> solved by the transport platform. > >>> In this case the link between the transport platform and the MPLS > >>> box is not a T-MPLS link and > >>> therefore it is outside the scope of T-MPLS > >> recommendations. We are > >>> looking for cooperation > >>> with IETF to develop the detailed specification of this case. > >>> Please find attached the text of the consented Recommendations. > >>> Please note that some minor > >>> modifications may be made to these draft Recommendations as a > >>> result of comments made during > >>> the approval process > >>> We will appreciate your comments and suggestions in > >> relation to the > >>> initial scope of T-MPLS as a > >>> packet transport network technology. > >>> We are planning to review your comments during the next meeting > >>> that is planned in Kobe (Japan) > >>> on 22-27 April 2006. Results of the comments will be included into > >>> our future work (e.g. corrigenda > >>> or amendments) on T-MPLS Recommendations. Amendments of T-MPLS > >>> Recommendations are > >>> already in our plan for the next SG15 plenary meeting in November > >>> 2006.We are looking forward > >>> for future cooperation with you in T-MPLS data plane and control > >>> plane evolution. > >>> > >>> Attachments: Consented Text of G.8110.1, G.8112, G.8121 > >>> Attachment(s): > >>> Consented Text of G.8110.1 (https://datatracker.ietf.org/ > >>> documents/LIAISON/file288.zip) > >>> Consented Text of G.8112 (https://datatracker.ietf.org/ > >>> documents/LIAISON/file289.zip) > >>> Consented Text of G.8121 (https://datatracker.ietf.org/ > >>> documents/LIAISON/file290.zip) > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 10:57:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKGr-0006Gs-5N; Tue, 11 Apr 2006 10:55:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKGq-0006Gn-LB for mpls@lists.ietf.org; Tue, 11 Apr 2006 10:55:08 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTKGq-0004ct-FM for mpls@lists.ietf.org; Tue, 11 Apr 2006 10:55:08 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 11 Apr 2006 10:55:08 -0400 X-IronPort-AV: i="4.04,112,1144036800"; d="scan'208"; a="86193911:sNHT28127046" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3BEsxWo005184; Tue, 11 Apr 2006 10:55:08 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 10:55:02 -0400 Received: from [10.86.242.57] ([10.86.242.57]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 10:55:02 -0400 Message-ID: <443BC345.3060803@employees.org> Date: Tue, 11 Apr 2006 10:55:01 -0400 From: Scott W Brim User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Shahram Davari Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns" References: <4B6D09F3B826D411A67300D0B706EFDE024333B6@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE024333B6@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Apr 2006 14:55:02.0268 (UTC) FILETIME=[E9440BC0:01C65D77] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: mpls@lists.ietf.org, "'Thomas D. Nadeau'" 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: , Errors-To: mpls-bounces@lists.ietf.org On 04/11/2006 10:16 AM, Shahram Davari allegedly wrote: > Hi Tom, > > 1) Reading the T-MPLS specs I didn't see any specific label range restriction. Where have you seen this? It's in G.8112. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 11:10:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKTD-0002zg-DX; Tue, 11 Apr 2006 11:07:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKTA-0002tj-Vl for mpls@lists.ietf.org; Tue, 11 Apr 2006 11:07:52 -0400 Received: from father.pmc-sierra.com ([216.241.224.13] helo=father.pmc-sierra.bc.ca) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTKT9-0005M1-Id for mpls@lists.ietf.org; Tue, 11 Apr 2006 11:07:52 -0400 Received: (qmail 20436 invoked by uid 101); 11 Apr 2006 15:07:50 -0000 Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59) by father.pmc-sierra.com with SMTP; 11 Apr 2006 15:07:50 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogmios.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k3BF7oY0026114; Tue, 11 Apr 2006 08:07:50 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id <132H3CHN>; Tue, 11 Apr 2006 08:07:50 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE024333BB@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> From: Shahram Davari To: "'Scott W Brim'" Subject: RE: [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns" Date: Tue, 11 Apr 2006 08:07:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: mpls@lists.ietf.org, "'Thomas D. Nadeau'" 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: , Errors-To: mpls-bounces@lists.ietf.org Hi Scott, The tabel in G.8112 diesn't show any restriction on label range. It is in-line with RFC-3032. It just repeats which of the 32 reserved labels are already in use, and which are for FFS. It also mentions that all the remaining 2^20-32 labels could be used for T-MPLS. What restriction do you see in that? -Shahram > -----Original Message----- > From: Scott W Brim [mailto:swb@employees.org] > Sent: Tuesday, April 11, 2006 10:55 AM > To: Shahram Davari > Cc: mpls@lists.ietf.org; 'Thomas D. Nadeau' > Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented > Recommendatio ns" > > > On 04/11/2006 10:16 AM, Shahram Davari allegedly wrote: > > Hi Tom, > > > > 1) Reading the T-MPLS specs I didn't see any specific label > range restriction. Where have you seen this? > > It's in G.8112. > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 11:11:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKUl-00043k-G5; Tue, 11 Apr 2006 11:09:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKUj-00043Q-H9 for mpls@lists.ietf.org; Tue, 11 Apr 2006 11:09:29 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTKUj-0005PE-03 for mpls@lists.ietf.org; Tue, 11 Apr 2006 11:09:29 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 11 Apr 2006 11:09:29 -0400 X-IronPort-AV: i="4.04,112,1144036800"; d="scan'208"; a="86196103:sNHT34065860" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3BF9SWc009255; Tue, 11 Apr 2006 11:09:28 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 11:09:28 -0400 Received: from [10.83.15.57] ([10.83.15.57]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 11:09:27 -0400 In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE024333B9@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> References: <4B6D09F3B826D411A67300D0B706EFDE024333B9@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5E3DFA9A-FCE1-4BE0-8435-3FC083A274F1@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns" Date: Tue, 11 Apr 2006 11:09:24 -0400 To: Shahram Davari X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 11 Apr 2006 15:09:28.0012 (UTC) FILETIME=[ED4A18C0:01C65D79] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Cc: mpls@lists.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: , Errors-To: mpls-bounces@lists.ietf.org > Why do you think T-MPLS is a completely different mechanism than MPLS? I didn't say that; please re-read what I posted. I said it is essentially a subset of functionality (sans the reserved label range and Y.1711). > Also why should the OAM for T-MPLS that is not using PHP, ECMP and > merging satisfy the > general OAM requirements as specified in RFC4377? How do you trace the LSP using Y.1711 or is that not an important function for OAM for T-MPLS? Also, from the IETF's perspective, we have already defined a tool set that satisfies all of the requirements of ping and trace (tree and path) in a single tool, which is now on the standards track, is widely deployed, and thus should be the tool specified herein. --Tom > -Shahram > >> -----Original Message----- >> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >> Sent: Tuesday, April 11, 2006 10:34 AM >> To: Shahram Davari >> Cc: mpls@lists.ietf.org >> Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented >> Recommendatio ns" >> >> >> >>> Hi Tom, >>> >>> 1) Reading the T-MPLS specs I didn't see any specific label range >>> restriction. Where have you seen this? >> >> See inline marked with "TOM:" >> >>> 2) The OAM specified is for T-MPLS, which as you said is a subset >>> of MPLS. Specifically T-MPLS doesn't include PHP, merging and ECMP >>> as indicated by the Liaison. So why should an OAM that is going to >>> be used for T-MPLS support those functions? >> >> The OAM as specified in the T-MPLS document is not a subset of >> MPLS; it is a completely different mechanism from what is specified >> at the IETF to meet the requirements in RFC4377. As described, y1711 >> acts on a sub-set of MPLS (lets forget about the label range), but >> does not meet all of the requirements as specified in RFC4377, >> even for this subset of MPLS. >> >> --Tom >> >> >> >>> >>> >>> Regards, >>> -Shahram >>> >>>> -----Original Message----- >>>> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>>> Sent: Tuesday, April 11, 2006 9:25 AM >>>> To: mpls@lists.ietf.org >>>> Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented >>>> Recommendations" >>>> >>>> >>>> [Resending to mpls list as I got a warning from the mailer >>>> that there was a suspicious number of recipients, so I am not >>>> sure it was delivered.] >>>> >>>> Hi, >>>> >>>> A few things in the ITU T-MPLS document concern me: >>>> >>>> 1) The document itself constitutes what is essentially >>>> two things: an protocol specification >>>> and an implementation guideline. >>>> >>>> For this reason, I first suggest that this document >>>> needs to be split into two: one that specifies >>>> the label range allocation (as well as requests >>>> it from the IETF), and a second that specifies >>>> the implementation guideline. I also suggest >>>> removal of "MPLS" from the name. This is very >>>> confusing, and implies that this document is >>>> some new standard for MPLS, whereas what it >>>> really specifies (sans the label range allocation >>>> and the OAM) is a subset of MPLS functionality. >>>> >>>> 2) With regard to the label range reservation, I am >>>> troubled by this because MPLS has been widely deployed >>>> without the said reserved label range. Deployment >>>> of LSRs that suddenly use this special label >>>> range will most likely lead to interoperability >>>> issues. I am also troubled by the lack of >>>> definition of what the reserved labels should >>>> be used for. If in the future, these labels are >>>> defined in a manner that is incompatible with >>>> existing LSRs, this will pose a significant >>>> hurdle to deployments. Again, a separate document that >>>> requests the label range, as well as specifies >>>> what they are to be used for is appropriate. >>>> >>>> 3) The OAM as specified does not meet the IETF's >>>> requirements for OAM specified in RFC4377. >>>> Y.1711 is not suitable for environments where PHP is >>>> enabled, and it also has other deficiencies such as a >>>> lack of tracing functionality, and cannot handle Equal >>>> Cost Multi-Path (ECMP) LSPs. In particular, section >>>> 4.3 of RFC4377 stipulates that path characterization >>>> functions must be able to work in these cases: >>>> >>>> 4.3. Path Characterization >>>> >>>> The path characterization function is the ability to >>>> reveal details >>>> of LSR forwarding operations. These details can then >> be compared >>>> during subsequent testing relevant to OAM functionality. This >>>> includes but is not limited to: >>>> >>>> - consistent use of pipe or uniform time to live >>>> (TTL) models by >>>> an LSR [RFC3443]. >>>> >>>> - sufficient details that allow the test origin to >>>> exercise all >>>> path permutations related to load spreading (e.g., ECMP). >>>> >>>> - stack operations performed by the LSR, such as pushes, >>>> pops, >>>> and TTL propagation at penultimate hop LSRs. >>>> >>>> I suggest replacing the reference to Y.1711 with a reference >>>> to rfc4377, rfc4378, and rfc4379. >>>> >>>> --Tom >>>> >>>> >>>> >>>>> Title: T-MPLS Consented Recommendations >>>>> Submission Date: 2006-04-02 >>>>> URL of the IETF Web page: https://datatracker.ietf.org/public/ >>>>> liaison_detail.cgi?detail_id=207 >>>>> Please reply by 2006-04-17 >>>>> >>>>> From: Greg Jones(ITU-T SG 15) >>>>> To: IETF MPLS WG, CC: MFA Forum(George Swallow >>>> , >>>>> Loa Andersson ) >>>>> Cc: info@mfaforum.org >>>>> maeda@ansl.ntt.co.jp >>>>> sjtrowbridge@lucent.com >>>>> rcallon@juniper.net >>>>> fenner@research.att.com >>>>> sob@harvard.edu >>>>> sbrim@cisco.com >>>>> mpls@lists.ietf.org >>>>> Reponse Contact: tsbsg15@itu.int >>>>> Technical Contact: Ghani.Abbas@marconi.com >>>>> mark.jones@sprint.com >>>>> betts01@nortel.com >>>>> Purpose: For action >>>>> Body: We apologize for not having sent a liaison regarding three >>>>> consented Recommendations related to >>>>> T-MPLS. The intent of these Recommendations is not to change MPLS >>>>> but rather to identify a >>>>> subset of existing MPLS necessary and sufficient to provide >>>>> connection-oriented packet transport. >>>>> The approach to the work was to make a profile of the MPLS data >>>>> plane functionalities defined in >>>>> IETF RFCs using the description of MPLS provided in G.8110 (which >>>>> was approved last year). >>>>> The intended application of this profile is to provide a >>>> connection- >>>>> oriented packet transport >>>>> network. >>>>> The focus of the three new recommendations is on the data plane >>>>> aspects of T-MPLS. Control plane >>>>> aspects are currently for further study and the work on this >>>>> subject is starting. >>>>> According to our work methodology the T-MPLS definitions are split >>>>> into the three main >>>>> Recommendations that have been consented in February 2006: >>>>> * G.8110.1 dealing with the T-MPLS Architecture >>>>> * G.8112 dealing with T-MPLS interface specification >>>>> * G.8121 dealing with T-MPLS equipment functional specification >>>>> A brief high-level introduction of the essential features and >>>>> selected options for Transport MPLS >>>>> can be found in section 6/G.8110.1. >>>>> The objective of the work done by ITU-T SG15 was to define >>>> a way to >>>>> use MPLS as a connection- >>>>> oriented packet-based transport solution for packet aware >>>> transport >>>>> networks that can support both >>>>> packet and circuit (e.g. SDH, OTH or WDM) switching technologies >>>>> under a common operation, >>>>> control and management paradigm. For this purpose T-MPLS deploys >>>>> the MPLS frame format, >>>>> Client to MPLS mapping and MPLS to MPLS multiplexing and >>>>> complements this with transport >>>>> network OAM (Y.1711), nested connection monitoring requiring the >>>>> labels to be present up to the >>>>> final node in the network, protection switching (Y.1720/G.8131), >>>>> transport network based control >>>>> and management planes, maintaining frame ordering and a restricted >>>>> number of classes of >>>>> service/queues. >>>>> * MPLS has many applications and it is desirable to identify a >>>>> subset of MPLS technology that >>>>> provides the necessary and sufficient functionality for transport >>>>> applications. >>>>> We have indicated below some of the options we have selected :- >>>>> * In IETF RFCs the usage of PHP is optional. We decided >>>> not to use >>>>> it in order to simplify OAM >>>>> procedures >>>>> * In IETF RFCs the usage of merging is optional. We >>>> decided not to >>>>> use it in order to simplify >>>>> OAM procedures and also because the relative lower number of LSPs >>>>> to be supported is not >>>>> considered a major scaling issue >>>>> * The usage of ECMP is optional. We decided not to use it >>>> in order >>>>> to simplify OAM procedures >>>>> * Leaving labels 16-31 for further study was seen as a no change >>>>> because the label allocation on a >> >> TOM: Read above. >> >>>>> link is defined in IETF RFCs as a local matter for any >> MPLS device. >>>>> We are not expecting that the current version of the specification >>>>> is going to create any >>>>> interoperability issue. We envisage two possible cases of >>>>> interoperability: >>>>> 1. Interoperability between a T-MPLS box and an >> existing full- >>>>> featured and fully configurable >>>>> MPLS box can be solved by configuring the MPLS box to use the same >>>>> options selected by T- >>>>> MPLS (T-MPLS being a profile of MPLS this should be possible). In >>>>> this case the link between >>>>> the two boxes is a T-MPLS link and in the scope of our >>>>> Recommendations. >>>>> 2. Interoperability between a transport platform >>>> supporting T-MPLS >>>>> and an existing MPLS box >>>>> that uses a different option selection than T-MPLS, should be >>>>> solved by the transport platform. >>>>> In this case the link between the transport platform and the MPLS >>>>> box is not a T-MPLS link and >>>>> therefore it is outside the scope of T-MPLS >>>> recommendations. We are >>>>> looking for cooperation >>>>> with IETF to develop the detailed specification of this case. >>>>> Please find attached the text of the consented Recommendations. >>>>> Please note that some minor >>>>> modifications may be made to these draft Recommendations as a >>>>> result of comments made during >>>>> the approval process >>>>> We will appreciate your comments and suggestions in >>>> relation to the >>>>> initial scope of T-MPLS as a >>>>> packet transport network technology. >>>>> We are planning to review your comments during the next meeting >>>>> that is planned in Kobe (Japan) >>>>> on 22-27 April 2006. Results of the comments will be included into >>>>> our future work (e.g. corrigenda >>>>> or amendments) on T-MPLS Recommendations. Amendments of T-MPLS >>>>> Recommendations are >>>>> already in our plan for the next SG15 plenary meeting in November >>>>> 2006.We are looking forward >>>>> for future cooperation with you in T-MPLS data plane and control >>>>> plane evolution. >>>>> >>>>> Attachments: Consented Text of G.8110.1, G.8112, G.8121 >>>>> Attachment(s): >>>>> Consented Text of G.8110.1 (https://datatracker.ietf.org/ >>>>> documents/LIAISON/file288.zip) >>>>> Consented Text of G.8112 (https://datatracker.ietf.org/ >>>>> documents/LIAISON/file289.zip) >>>>> Consented Text of G.8121 (https://datatracker.ietf.org/ >>>>> documents/LIAISON/file290.zip) >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 11:27:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKk9-0003X4-1X; Tue, 11 Apr 2006 11:25:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKk7-0003Wz-G5 for mpls@lists.ietf.org; Tue, 11 Apr 2006 11:25:23 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTKk5-00068X-8i for mpls@lists.ietf.org; Tue, 11 Apr 2006 11:25:23 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 11 Apr 2006 11:25:22 -0400 X-IronPort-AV: i="4.04,112,1144036800"; d="scan'208"; a="86198480:sNHT29536724" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3BFPKVU008228; Tue, 11 Apr 2006 11:25:20 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 11:25:20 -0400 Received: from swallow-mini-mac.local ([10.86.240.218]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 11:25:20 -0400 Received: from cisco.com (localhost [127.0.0.1]) by swallow-mini-mac.local (Postfix) with ESMTP id D4175228495; Tue, 11 Apr 2006 11:25:19 -0400 (EDT) To: neil.2.harrison@bt.com Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented Recommendations" In-reply-to: Your message of "Tue, 11 Apr 2006 15:26:25 BST." <0536FC9B908BEC4597EE721BE6A353891576C7E5@i2km07-ukbr.domain1.systemhost.net> From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 Date: Tue, 11 Apr 2006 11:25:19 -0400 Message-Id: <20060411152519.D4175228495@swallow-mini-mac.local> X-OriginalArrivalTime: 11 Apr 2006 15:25:20.0435 (UTC) FILETIME=[24FA5030:01C65D7C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: mpls@lists.ietf.org, tnadeau@cisco.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Neil - > (i) I agree with you that some clarity is required on > specific reserved label ranges and their uses. However, I'd > say it's bigger than just the label ranges and should also > include how all the header fields (ie S, EXP, TTL) are to be Could you enlighten us as to what you are considering here. Prima facia, it would appear that you are diverting further from MPLS than the liaised material would indicate.... > used in T-MPLS (I noted you don't think this 'T-MPLS' name is > good, but I'll stick with it here). Why? Well, folks need > to consider the various client/server relationships that > could exist between the various spins of MPLS as-is and > T-MPLS....and especially misconnectivity between them....so > how is this going to be handled? We handle such relationships for ATM, SONET, Ethernet without calling any of those MPLS. I see no argument here for including MPLS in the name of your transport technology. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 11:33:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKqE-0005cR-Dp; Tue, 11 Apr 2006 11:31:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKqC-0005cM-6b for mpls@lists.ietf.org; Tue, 11 Apr 2006 11:31:40 -0400 Received: from mail124.messagelabs.com ([85.158.136.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTKqA-0006Kt-Nd for mpls@lists.ietf.org; Tue, 11 Apr 2006 11:31:40 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-8.tower-124.messagelabs.com!1144769421!8846764!25 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 14124 invoked from network); 11 Apr 2006 15:31:37 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-8.tower-124.messagelabs.com with SMTP; 11 Apr 2006 15:31:37 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 4426C9FE0021D13C; Tue, 11 Apr 2006 11:31:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] New Liaison Statement, "T-MPLS Consented Recommendations" Date: Tue, 11 Apr 2006 10:31:35 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7624@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <8452A02A-4204-4F2F-946E-DA644CF50F45@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] New Liaison Statement, "T-MPLS Consented Recommendations" Thread-Index: AcZda2b2Xy2mCYjxThuY0hck9PmvxAAEJEbA From: "Ash, Gerald R \(Jerry\), ALABS" To: "Thomas D. Nadeau" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org > The OAM as specified does not meet the IETF's > requirements for OAM specified in RFC4377. > Y.1711 is not suitable for environments where PHP is > enabled, It isn't clear why ITU-T did not also specify Y.1713 (MPLS OAM Connection Verify Mechanism compatible with LDP, shepherded through ITU-T by David Allan) Jerry _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 11:35:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKsY-0007N7-0O; Tue, 11 Apr 2006 11:34:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKsW-0007N2-9J for mpls@lists.ietf.org; Tue, 11 Apr 2006 11:34:04 -0400 Received: from father.pmc-sierra.com ([216.241.224.13] helo=father.pmc-sierra.bc.ca) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTKsU-0006VR-Se for mpls@lists.ietf.org; Tue, 11 Apr 2006 11:34:04 -0400 Received: (qmail 28049 invoked by uid 101); 11 Apr 2006 15:34:01 -0000 Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59) by father.pmc-sierra.com with SMTP; 11 Apr 2006 15:34:01 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogmios.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k3BFY1tl003067; Tue, 11 Apr 2006 08:34:01 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id <132H3DCW>; Tue, 11 Apr 2006 08:34:00 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE024333BD@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> From: Shahram Davari To: "'Ash, Gerald R (Jerry), ALABS'" , "Thomas D. Nadeau" , mpls@lists.ietf.org Subject: RE: [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns" Date: Tue, 11 Apr 2006 08:33:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org My guess: because it is not needed for T-MPLS, since T-MPLS doesn't support label merging (aka LDP). -Shahram > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > Sent: Tuesday, April 11, 2006 11:32 AM > To: Thomas D. Nadeau; mpls@lists.ietf.org > Subject: RE: [mpls] New Liaison Statement, "T-MPLS Consented > Recommendations" > > > > The OAM as specified does not meet the IETF's > > requirements for OAM specified in RFC4377. > > Y.1711 is not suitable for environments where PHP is > > enabled, > > It isn't clear why ITU-T did not also specify Y.1713 (MPLS OAM > Connection Verify Mechanism compatible with LDP, shepherded through > ITU-T by David Allan) > > Jerry > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 11:45:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTL1Q-0002PX-CB; Tue, 11 Apr 2006 11:43:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTL1O-0002PK-BI for mpls@lists.ietf.org; Tue, 11 Apr 2006 11:43:14 -0400 Received: from father.pmc-sierra.com ([216.241.224.13] helo=father.pmc-sierra.bc.ca) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTL1N-0006s8-TB for mpls@lists.ietf.org; Tue, 11 Apr 2006 11:43:14 -0400 Received: (qmail 441 invoked by uid 101); 11 Apr 2006 15:43:12 -0000 Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59) by father.pmc-sierra.com with SMTP; 11 Apr 2006 15:43:12 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogmios.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k3BFhCOE006284; Tue, 11 Apr 2006 08:43:12 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id <132H3DNQ>; Tue, 11 Apr 2006 08:43:12 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE024333BE@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> From: Shahram Davari To: "'George Swallow'" , neil.2.harrison@bt.com Subject: RE: [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns" Date: Tue, 11 Apr 2006 08:43:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: mpls@lists.ietf.org, tnadeau@cisco.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Tuesday, April 11, 2006 11:25 AM > To: neil.2.harrison@bt.com > Cc: mpls@lists.ietf.org; tnadeau@cisco.com > Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented > Recommendations" > > > Neil - > > > (i) I agree with you that some clarity is required on > > specific reserved label ranges and their uses. However, I'd > > say it's bigger than just the label ranges and should also > > include how all the header fields (ie S, EXP, TTL) are to be > > Could you enlighten us as to what you are considering here. Prima > facia, it would appear that you are diverting further from > MPLS than the > liaised material would indicate.... > > > used in T-MPLS (I noted you don't think this 'T-MPLS' name is > > good, but I'll stick with it here). Why? Well, folks need > > to consider the various client/server relationships that > > could exist between the various spins of MPLS as-is and > > T-MPLS....and especially misconnectivity between them....so > > how is this going to be handled? > > We handle such relationships for ATM, SONET, Ethernet without calling > any of those MPLS. I see no argument here for including MPLS in the > name of your transport technology. But none of them uses MPLS packet format: MPLS label, TTL, EXP, and switch based on the 20-bit label, and use EXP-bit to identify the CoS/DP, and use TTL for loop detection. MPLS, by Design, consists of two distinct planes: data-plane and control-plane. If the control-plane nails down only one specific path for an LSP, using say RSVP-TE, then there is no ECMP and merging. Additinally since PHP is optional, there is no mandate to support it. So are you saying a technology that uses MPLS data-plane, but its control-plane doesn't support ECMP, merging or PHP is not MPLS? -Shahram > > ...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 > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 11:45:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTL1R-0002Ra-2K; Tue, 11 Apr 2006 11:43:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTL1O-0002PS-Kc for mpls@lists.ietf.org; Tue, 11 Apr 2006 11:43:14 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTL1O-0006sG-Da for mpls@lists.ietf.org; Tue, 11 Apr 2006 11:43:14 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 11 Apr 2006 11:43:14 -0400 X-IronPort-AV: i="4.04,112,1144036800"; d="scan'208"; a="86200876:sNHT30126056" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3BFh9We018045; Tue, 11 Apr 2006 11:43:14 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 11:43:09 -0400 Received: from [10.86.242.57] ([10.86.242.57]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 11:43:09 -0400 Message-ID: <443BCE8C.6040109@employees.org> Date: Tue, 11 Apr 2006 11:43:08 -0400 From: Scott W Brim User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Shahram Davari Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns" References: <4B6D09F3B826D411A67300D0B706EFDE024333BB@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE024333BB@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Apr 2006 15:43:09.0223 (UTC) FILETIME=[A2066B70:01C65D7E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: mpls@lists.ietf.org, "'Thomas D. Nadeau'" 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: , Errors-To: mpls-bounces@lists.ietf.org On 04/11/2006 11:07 AM, Shahram Davari allegedly wrote: > Hi Scott, > > The tabel in G.8112 diesn't show any restriction on label range. It > is in-line with RFC-3032. It just repeats which of the 32 reserved > labels are already in use, and which are for FFS. It also mentions > that all the remaining 2^20-32 labels could be used for T-MPLS. What > restriction do you see in that? > > -Shahram In 3032, labels 0-3 have special use and 4-15 are reserved. G.8112 (table 6-7) extends this by saying: "16-31 For further study". Existing implementations use these labels by default -- some cannot be configured not to. Cisco put in a comment suggesting this be modified to "16-31 For further study in consultation with the IETF". The editor responded suggesting "16-31 Not used in T-MPLS" and a note: "Labels 16-31 are, by convention, not used in T-MPLS. If used in the future, they will be used in the context of label pop, push or swap as defined in RFC3031 and RFC3032." I have trouble seeing the difference. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 11:50:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTL6H-0003WY-Lo; Tue, 11 Apr 2006 11:48:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTL6G-0003S3-8B for mpls@lists.ietf.org; Tue, 11 Apr 2006 11:48:16 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTL6F-00075Y-P5 for mpls@lists.ietf.org; Tue, 11 Apr 2006 11:48:16 -0400 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 16:48:15 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 16:48:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] New Liaison Statement, "T-MPLS Consented Recommendations" Date: Tue, 11 Apr 2006 16:48:14 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353891576CA24@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] New Liaison Statement, "T-MPLS Consented Recommendations" Thread-Index: AcZdfCoZQS5S5mvuT2agCjjNqBHuHQAAMeAQ From: To: X-OriginalArrivalTime: 11 Apr 2006 15:48:14.0645 (UTC) FILETIME=[58121E50:01C65D7F] X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: mpls@lists.ietf.org, tnadeau@cisco.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Thanks George....please see below. >=20 > Neil - >=20 > > (i) I agree with you that some clarity is required on=20 > > specific reserved label ranges and their uses. However, I'd > > say it's bigger than just the label ranges and should also=20 > > include how all the header fields (ie S, EXP, TTL) are to be=20 >=20 > Could you enlighten us as to what you are considering here. =20 > Prima facia, it would appear that you are diverting further=20 > from MPLS than the liaised material would indicate.... NH=3D> Let me state up front that I have no axe to grind wrt = T-MPLS....so all I was saying here is that folks need to look at more than just the label field of the traffic unit and be clear they understand how this works in T-MPLS. =20 >=20 > > used in T-MPLS (I noted you don't think this 'T-MPLS' name is > > good, but I'll stick with it here). Why? Well, folks need=20 > > to consider the various client/server relationships that=20 > > could exist between the various spins of MPLS as-is and=20 > > T-MPLS....and especially misconnectivity between them....so=20 > > how is this going to be handled? >=20 > We handle such relationships for ATM, SONET, Ethernet without=20 > calling any of those MPLS. I see no argument here for=20 > including MPLS in the name of your transport technology. NH=3D> This is not *my* transport technology please note. But it seems you are missing my point here.....so let me be more explicit. If I take FR and ATM these represent 2 different co-ps mode layer networks, and they use quite different traffic units...obvious, right? It's quite clear here that misconnectivity defects between the FR and ATM layer networks have a fundamental traffic unit conflict which makes them impossible. Now if I take the LDP spin of MPLS and T-MPLS these also represent 2 different layer networks but they will be based on the same traffic unit. So if these 2 layer networks can co-exist in the same box there is more concern about misconnectivity. Hopefully that clarifies my concern. regards, Neil _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 11:50:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTL6k-0004Yv-CE; Tue, 11 Apr 2006 11:48:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTL6i-0004Yl-L7 for mpls@lists.ietf.org; Tue, 11 Apr 2006 11:48:44 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTL6h-000772-UB for mpls@lists.ietf.org; Tue, 11 Apr 2006 11:48:44 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 16:48:43 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 16:48:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns" Date: Tue, 11 Apr 2006 16:48:41 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353891576CA27@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns" Thread-Index: AcZdenzu7E64aSaQScef/ewCZSo4PwAAWiQQ From: To: , X-OriginalArrivalTime: 11 Apr 2006 15:48:42.0361 (UTC) FILETIME=[68973E90:01C65D7F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Cc: mpls@lists.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: , Errors-To: mpls-bounces@lists.ietf.org > How do you trace the LSP using Y.1711 or is that > not an important function for OAM for T-MPLS? Also, from the=20 > IETF's perspective, we have already defined a tool set that=20 > satisfies all of the requirements of ping and trace (tree and=20 > path) in a single tool, which is now on the standards track,=20 > is widely deployed, and thus should be the tool specified herein. Tom, tracing in a co-ps mode technology that respects connection requirements should be a whole lot easier than in one than does not. So I would argue that you can re-use the same diagnostic tools in T-MPLS. BTW - We really should start with a definition of defects including entry/exit criteria...everything else builds on this baseline. Unless one has a proper connection however, I really don't see how this is possible. =20 regards, Neil >=20 > --Tom >=20 >=20 > > -Shahram > > > >> -----Original Message----- > >> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >> Sent: Tuesday, April 11, 2006 10:34 AM > >> To: Shahram Davari > >> Cc: mpls@lists.ietf.org > >> Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented=20 > >> Recommendatio ns" > >> > >> > >> > >>> Hi Tom, > >>> > >>> 1) Reading the T-MPLS specs I didn't see any specific label range=20 > >>> restriction. Where have you seen this? > >> > >> See inline marked with "TOM:" > >> > >>> 2) The OAM specified is for T-MPLS, which as you said is=20 > a subset of=20 > >>> MPLS. Specifically T-MPLS doesn't include PHP, merging=20 > and ECMP as=20 > >>> indicated by the Liaison. So why should an OAM that is=20 > going to be=20 > >>> used for T-MPLS support those functions? > >> > >> The OAM as specified in the T-MPLS document is not a=20 > subset of MPLS;=20 > >> it is a completely different mechanism from what is=20 > specified at the=20 > >> IETF to meet the requirements in RFC4377. As described,=20 > y1711 acts on=20 > >> a sub-set of MPLS (lets forget about the label range), but=20 > does not=20 > >> meet all of the requirements as specified in RFC4377, even=20 > for this=20 > >> subset of MPLS. > >> > >> --Tom > >> > >> > >> > >>> > >>> > >>> Regards, > >>> -Shahram > >>> > >>>> -----Original Message----- > >>>> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >>>> Sent: Tuesday, April 11, 2006 9:25 AM > >>>> To: mpls@lists.ietf.org > >>>> Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented=20 > >>>> Recommendations" > >>>> > >>>> > >>>> [Resending to mpls list as I got a warning from the mailer that=20 > >>>> there was a suspicious number of recipients, so I am not sure it=20 > >>>> was delivered.] > >>>> > >>>> Hi, > >>>> > >>>> A few things in the ITU T-MPLS document concern me: > >>>> > >>>> 1) The document itself constitutes what is essentially > >>>> two things: an protocol specification > >>>> and an implementation guideline. > >>>> > >>>> For this reason, I first suggest that this document > >>>> needs to be split into two: one that specifies > >>>> the label range allocation (as well as requests > >>>> it from the IETF), and a second that specifies > >>>> the implementation guideline. I also suggest > >>>> removal of "MPLS" from the name. This is very > >>>> confusing, and implies that this document is > >>>> some new standard for MPLS, whereas what it > >>>> really specifies (sans the label range allocation > >>>> and the OAM) is a subset of MPLS functionality. > >>>> > >>>> 2) With regard to the label range reservation, I am > >>>> troubled by this because MPLS has been widely deployed > >>>> without the said reserved label range. Deployment > >>>> of LSRs that suddenly use this special label > >>>> range will most likely lead to interoperability > >>>> issues. I am also troubled by the lack of > >>>> definition of what the reserved labels should > >>>> be used for. If in the future, these labels are > >>>> defined in a manner that is incompatible with > >>>> existing LSRs, this will pose a significant > >>>> hurdle to deployments. Again, a separate document that > >>>> requests the label range, as well as specifies > >>>> what they are to be used for is appropriate. > >>>> > >>>> 3) The OAM as specified does not meet the IETF's > >>>> requirements for OAM specified in RFC4377. > >>>> Y.1711 is not suitable for environments where PHP is > >>>> enabled, and it also has other deficiencies such as a > >>>> lack of tracing functionality, and cannot handle Equal > >>>> Cost Multi-Path (ECMP) LSPs. In particular, section > >>>> 4.3 of RFC4377 stipulates that path characterization > >>>> functions must be able to work in these cases: > >>>> > >>>> 4.3. Path Characterization > >>>> > >>>> The path characterization function is the ability to reveal=20 > >>>> details > >>>> of LSR forwarding operations. These details can then > >> be compared > >>>> during subsequent testing relevant to OAM=20 > functionality. This > >>>> includes but is not limited to: > >>>> > >>>> - consistent use of pipe or uniform time to live > >>>> (TTL) models by > >>>> an LSR [RFC3443]. > >>>> > >>>> - sufficient details that allow the test origin=20 > to exercise=20 > >>>> all > >>>> path permutations related to load spreading=20 > (e.g., ECMP). > >>>> > >>>> - stack operations performed by the LSR, such as pushes,=20 > >>>> pops, > >>>> and TTL propagation at penultimate hop LSRs. > >>>> > >>>> I suggest replacing the reference to Y.1711 with a reference > >>>> to rfc4377, rfc4378, and rfc4379. > >>>> > >>>> --Tom > >>>> > >>>> > >>>> > >>>>> Title: T-MPLS Consented Recommendations > >>>>> Submission Date: 2006-04-02 > >>>>> URL of the IETF Web page: https://datatracker.ietf.org/public/ > >>>>> liaison_detail.cgi?detail_id=3D207 > >>>>> Please reply by 2006-04-17 > >>>>> > >>>>> From: Greg Jones(ITU-T SG 15) > >>>>> To: IETF MPLS WG, CC: MFA Forum(George Swallow > >>>> , > >>>>> Loa Andersson ) > >>>>> Cc: info@mfaforum.org > >>>>> maeda@ansl.ntt.co.jp > >>>>> sjtrowbridge@lucent.com > >>>>> rcallon@juniper.net > >>>>> fenner@research.att.com > >>>>> sob@harvard.edu > >>>>> sbrim@cisco.com > >>>>> mpls@lists.ietf.org > >>>>> Reponse Contact: tsbsg15@itu.int > >>>>> Technical Contact: Ghani.Abbas@marconi.com mark.jones@sprint.com > >>>>> betts01@nortel.com > >>>>> Purpose: For action > >>>>> Body: We apologize for not having sent a liaison regarding three > >>>>> consented Recommendations related to > >>>>> T-MPLS. The intent of these Recommendations is not to=20 > change MPLS > >>>>> but rather to identify a > >>>>> subset of existing MPLS necessary and sufficient to provide > >>>>> connection-oriented packet transport. > >>>>> The approach to the work was to make a profile of the MPLS data > >>>>> plane functionalities defined in > >>>>> IETF RFCs using the description of MPLS provided in=20 > G.8110 (which > >>>>> was approved last year). > >>>>> The intended application of this profile is to provide a > >>>> connection- > >>>>> oriented packet transport > >>>>> network. > >>>>> The focus of the three new recommendations is on the data plane=20 > >>>>> aspects of T-MPLS. Control plane aspects are currently=20 > for further=20 > >>>>> study and the work on this subject is starting. > >>>>> According to our work methodology the T-MPLS=20 > definitions are split > >>>>> into the three main > >>>>> Recommendations that have been consented in February 2006: > >>>>> * G.8110.1 dealing with the T-MPLS Architecture > >>>>> * G.8112 dealing with T-MPLS interface specification > >>>>> * G.8121 dealing with T-MPLS equipment functional=20 > specification > >>>>> A brief high-level introduction of the essential features and > >>>>> selected options for Transport MPLS > >>>>> can be found in section 6/G.8110.1. > >>>>> The objective of the work done by ITU-T SG15 was to define > >>>> a way to > >>>>> use MPLS as a connection- > >>>>> oriented packet-based transport solution for packet aware > >>>> transport > >>>>> networks that can support both > >>>>> packet and circuit (e.g. SDH, OTH or WDM) switching=20 > technologies=20 > >>>>> under a common operation, control and management paradigm. For=20 > >>>>> this purpose T-MPLS deploys the MPLS frame format, > >>>>> Client to MPLS mapping and MPLS to MPLS multiplexing and > >>>>> complements this with transport > >>>>> network OAM (Y.1711), nested connection monitoring requiring the > >>>>> labels to be present up to the > >>>>> final node in the network, protection switching (Y.1720/G.8131), > >>>>> transport network based control > >>>>> and management planes, maintaining frame ordering and a=20 > restricted > >>>>> number of classes of > >>>>> service/queues. > >>>>> * MPLS has many applications and it is desirable=20 > to identify a > >>>>> subset of MPLS technology that > >>>>> provides the necessary and sufficient functionality for=20 > transport > >>>>> applications. > >>>>> We have indicated below some of the options we have selected :- > >>>>> * In IETF RFCs the usage of PHP is optional. We decided > >>>> not to use > >>>>> it in order to simplify OAM > >>>>> procedures > >>>>> * In IETF RFCs the usage of merging is optional. We > >>>> decided not to > >>>>> use it in order to simplify > >>>>> OAM procedures and also because the relative lower=20 > number of LSPs=20 > >>>>> to be supported is not considered a major scaling issue > >>>>> * The usage of ECMP is optional. We decided not to use it > >>>> in order > >>>>> to simplify OAM procedures > >>>>> * Leaving labels 16-31 for further study was seen=20 > as a no change > >>>>> because the label allocation on a > >> > >> TOM: Read above. > >> > >>>>> link is defined in IETF RFCs as a local matter for any > >> MPLS device. > >>>>> We are not expecting that the current version of the=20 > specification=20 > >>>>> is going to create any interoperability issue. We envisage two=20 > >>>>> possible cases of > >>>>> interoperability: > >>>>> 1. Interoperability between a T-MPLS box and an > >> existing full- > >>>>> featured and fully configurable > >>>>> MPLS box can be solved by configuring the MPLS box to=20 > use the same=20 > >>>>> options selected by T- MPLS (T-MPLS being a profile of=20 > MPLS this=20 > >>>>> should be possible). In this case the link between > >>>>> the two boxes is a T-MPLS link and in the scope of our > >>>>> Recommendations. > >>>>> 2. Interoperability between a transport platform > >>>> supporting T-MPLS > >>>>> and an existing MPLS box > >>>>> that uses a different option selection than T-MPLS, should be=20 > >>>>> solved by the transport platform. In this case the link between=20 > >>>>> the transport platform and the MPLS box is not a T-MPLS link and > >>>>> therefore it is outside the scope of T-MPLS > >>>> recommendations. We are > >>>>> looking for cooperation > >>>>> with IETF to develop the detailed specification of this case.=20 > >>>>> Please find attached the text of the consented Recommendations.=20 > >>>>> Please note that some minor modifications may be made to these=20 > >>>>> draft Recommendations as a result of comments made during > >>>>> the approval process > >>>>> We will appreciate your comments and suggestions in > >>>> relation to the > >>>>> initial scope of T-MPLS as a > >>>>> packet transport network technology. > >>>>> We are planning to review your comments during the next meeting=20 > >>>>> that is planned in Kobe (Japan) on 22-27 April 2006. Results of=20 > >>>>> the comments will be included into our future work (e.g.=20 > >>>>> corrigenda or amendments) on T-MPLS Recommendations.=20 > Amendments of=20 > >>>>> T-MPLS Recommendations are > >>>>> already in our plan for the next SG15 plenary meeting=20 > in November > >>>>> 2006.We are looking forward > >>>>> for future cooperation with you in T-MPLS data plane and control > >>>>> plane evolution. > >>>>> > >>>>> Attachments: Consented Text of G.8110.1, G.8112, G.8121 > >>>>> Attachment(s): > >>>>> Consented Text of G.8110.1 (https://datatracker.ietf.org/ > >>>>> documents/LIAISON/file288.zip) > >>>>> Consented Text of G.8112 (https://datatracker.ietf.org/ > >>>>> documents/LIAISON/file289.zip) > >>>>> Consented Text of G.8121 (https://datatracker.ietf.org/ > >>>>> documents/LIAISON/file290.zip) > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >> > > > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 11:59:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLFk-0000Uo-D4; Tue, 11 Apr 2006 11:58:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLFi-0000Uj-Oa for mpls@lists.ietf.org; Tue, 11 Apr 2006 11:58:02 -0400 Received: from mother.pmc-sierra.com ([216.241.224.12] helo=mother.pmc-sierra.bc.ca) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTLFi-0007Ld-FB for mpls@lists.ietf.org; Tue, 11 Apr 2006 11:58:02 -0400 Received: (qmail 22478 invoked by uid 101); 11 Apr 2006 15:57:58 -0000 Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59) by mother.pmc-sierra.com with SMTP; 11 Apr 2006 15:57:58 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogmios.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k3BFvvdZ011443; Tue, 11 Apr 2006 08:57:57 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id <132H3D8P>; Tue, 11 Apr 2006 08:57:57 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE024333BF@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> From: Shahram Davari To: "'Scott W Brim'" Subject: RE: [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns" Date: Tue, 11 Apr 2006 08:57:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: mpls@lists.ietf.org, "'Thomas D. Nadeau'" 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: , Errors-To: mpls-bounces@lists.ietf.org Ok, now I go it. I think this should be corrected, specially when there is no use for it. -Shahram > -----Original Message----- > From: Scott W Brim [mailto:swb@employees.org] > Sent: Tuesday, April 11, 2006 11:43 AM > To: Shahram Davari > Cc: mpls@lists.ietf.org; 'Thomas D. Nadeau' > Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented > Recommendatio ns" > > > On 04/11/2006 11:07 AM, Shahram Davari allegedly wrote: > > Hi Scott, > > > > The tabel in G.8112 diesn't show any restriction on label range. It > > is in-line with RFC-3032. It just repeats which of the 32 reserved > > labels are already in use, and which are for FFS. It also mentions > > that all the remaining 2^20-32 labels could be used for T-MPLS. What > > restriction do you see in that? > > > > -Shahram > > In 3032, labels 0-3 have special use and 4-15 are reserved. G.8112 > (table 6-7) extends this by saying: "16-31 For further > study". Existing > implementations use these labels by default -- some cannot be > configured > not to. > > Cisco put in a comment suggesting this be modified to "16-31 For > further study in consultation with the IETF". The editor responded > suggesting "16-31 Not used in T-MPLS" and a note: "Labels > 16-31 are, by > convention, not used in T-MPLS. If used in the future, they > will be used > in the context of label pop, push or swap as defined in RFC3031 and > RFC3032." I have trouble seeing the difference. > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 12:20:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLXf-0001oT-DY; Tue, 11 Apr 2006 12:16:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLXe-0001oO-CY for mpls@lists.ietf.org; Tue, 11 Apr 2006 12:16:34 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTLXc-00089b-LG for mpls@lists.ietf.org; Tue, 11 Apr 2006 12:16:34 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 11 Apr 2006 09:16:32 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,112,1144047600"; d="scan'208"; a="25656870:sNHT30160728" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3BGGVWc025115; Tue, 11 Apr 2006 12:16:31 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 12:16:31 -0400 Received: from [10.83.15.57] ([10.83.15.57]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 12:16:30 -0400 In-Reply-To: <0536FC9B908BEC4597EE721BE6A353891576CA27@i2km07-ukbr.domain1.systemhost.net> References: <0536FC9B908BEC4597EE721BE6A353891576CA27@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6692F7DC-A460-4BA4-8ED3-CB76F3366E6D@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns" Date: Tue, 11 Apr 2006 12:16:31 -0400 To: X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 11 Apr 2006 16:16:30.0830 (UTC) FILETIME=[4B1368E0:01C65D83] X-Spam-Score: 0.0 (/) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 Cc: mpls@lists.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: , Errors-To: mpls-bounces@lists.ietf.org On Apr 11, 2006, at 11:48 AM, wrote: >> How do you trace the LSP using Y.1711 or is that >> not an important function for OAM for T-MPLS? Also, from the >> IETF's perspective, we have already defined a tool set that >> satisfies all of the requirements of ping and trace (tree and >> path) in a single tool, which is now on the standards track, >> is widely deployed, and thus should be the tool specified herein. > > Tom, tracing in a co-ps mode technology that respects connection > requirements should be a whole lot easier than in one than does > not. So > I would argue that you can re-use the same diagnostic tools in T-MPLS. Theory and practice are very different when it comes to data plane diagnostics vs. control plane. Hoping that it is easier and ensuring that it actually works %100 of the time are two quite different things. Also, as someone who works at a network operator, you surely can appreciate the advantages of using a single mechanism for fault-detection and trouble-shooting, especially if it is widely deployed and available. --Tom > BTW - We really should start with a definition of defects including > entry/exit criteria...everything else builds on this baseline. Unless > one has a proper connection however, I really don't see how this is > possible. > > regards, Neil >> >> --Tom >> >> >>> -Shahram >>> >>>> -----Original Message----- >>>> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>>> Sent: Tuesday, April 11, 2006 10:34 AM >>>> To: Shahram Davari >>>> Cc: mpls@lists.ietf.org >>>> Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented >>>> Recommendatio ns" >>>> >>>> >>>> >>>>> Hi Tom, >>>>> >>>>> 1) Reading the T-MPLS specs I didn't see any specific label range >>>>> restriction. Where have you seen this? >>>> >>>> See inline marked with "TOM:" >>>> >>>>> 2) The OAM specified is for T-MPLS, which as you said is >> a subset of >>>>> MPLS. Specifically T-MPLS doesn't include PHP, merging >> and ECMP as >>>>> indicated by the Liaison. So why should an OAM that is >> going to be >>>>> used for T-MPLS support those functions? >>>> >>>> The OAM as specified in the T-MPLS document is not a >> subset of MPLS; >>>> it is a completely different mechanism from what is >> specified at the >>>> IETF to meet the requirements in RFC4377. As described, >> y1711 acts on >>>> a sub-set of MPLS (lets forget about the label range), but >> does not >>>> meet all of the requirements as specified in RFC4377, even >> for this >>>> subset of MPLS. >>>> >>>> --Tom >>>> >>>> >>>> >>>>> >>>>> >>>>> Regards, >>>>> -Shahram >>>>> >>>>>> -----Original Message----- >>>>>> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>>>>> Sent: Tuesday, April 11, 2006 9:25 AM >>>>>> To: mpls@lists.ietf.org >>>>>> Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented >>>>>> Recommendations" >>>>>> >>>>>> >>>>>> [Resending to mpls list as I got a warning from the mailer that >>>>>> there was a suspicious number of recipients, so I am not sure it >>>>>> was delivered.] >>>>>> >>>>>> Hi, >>>>>> >>>>>> A few things in the ITU T-MPLS document concern me: >>>>>> >>>>>> 1) The document itself constitutes what is essentially >>>>>> two things: an protocol specification >>>>>> and an implementation guideline. >>>>>> >>>>>> For this reason, I first suggest that this document >>>>>> needs to be split into two: one that specifies >>>>>> the label range allocation (as well as requests >>>>>> it from the IETF), and a second that specifies >>>>>> the implementation guideline. I also suggest >>>>>> removal of "MPLS" from the name. This is very >>>>>> confusing, and implies that this document is >>>>>> some new standard for MPLS, whereas what it >>>>>> really specifies (sans the label range allocation >>>>>> and the OAM) is a subset of MPLS functionality. >>>>>> >>>>>> 2) With regard to the label range reservation, I am >>>>>> troubled by this because MPLS has been widely deployed >>>>>> without the said reserved label range. Deployment >>>>>> of LSRs that suddenly use this special label >>>>>> range will most likely lead to interoperability >>>>>> issues. I am also troubled by the lack of >>>>>> definition of what the reserved labels should >>>>>> be used for. If in the future, these labels are >>>>>> defined in a manner that is incompatible with >>>>>> existing LSRs, this will pose a significant >>>>>> hurdle to deployments. Again, a separate document that >>>>>> requests the label range, as well as specifies >>>>>> what they are to be used for is appropriate. >>>>>> >>>>>> 3) The OAM as specified does not meet the IETF's >>>>>> requirements for OAM specified in RFC4377. >>>>>> Y.1711 is not suitable for environments where PHP is >>>>>> enabled, and it also has other deficiencies such as a >>>>>> lack of tracing functionality, and cannot handle Equal >>>>>> Cost Multi-Path (ECMP) LSPs. In particular, section >>>>>> 4.3 of RFC4377 stipulates that path characterization >>>>>> functions must be able to work in these cases: >>>>>> >>>>>> 4.3. Path Characterization >>>>>> >>>>>> The path characterization function is the ability to reveal >>>>>> details >>>>>> of LSR forwarding operations. These details can then >>>> be compared >>>>>> during subsequent testing relevant to OAM >> functionality. This >>>>>> includes but is not limited to: >>>>>> >>>>>> - consistent use of pipe or uniform time to live >>>>>> (TTL) models by >>>>>> an LSR [RFC3443]. >>>>>> >>>>>> - sufficient details that allow the test origin >> to exercise >>>>>> all >>>>>> path permutations related to load spreading >> (e.g., ECMP). >>>>>> >>>>>> - stack operations performed by the LSR, such as pushes, >>>>>> pops, >>>>>> and TTL propagation at penultimate hop LSRs. >>>>>> >>>>>> I suggest replacing the reference to Y.1711 with a reference >>>>>> to rfc4377, rfc4378, and rfc4379. >>>>>> >>>>>> --Tom >>>>>> >>>>>> >>>>>> >>>>>>> Title: T-MPLS Consented Recommendations >>>>>>> Submission Date: 2006-04-02 >>>>>>> URL of the IETF Web page: https://datatracker.ietf.org/public/ >>>>>>> liaison_detail.cgi?detail_id=207 >>>>>>> Please reply by 2006-04-17 >>>>>>> >>>>>>> From: Greg Jones(ITU-T SG 15) >>>>>>> To: IETF MPLS WG, CC: MFA Forum(George Swallow >>>>>> , >>>>>>> Loa Andersson ) >>>>>>> Cc: info@mfaforum.org >>>>>>> maeda@ansl.ntt.co.jp >>>>>>> sjtrowbridge@lucent.com >>>>>>> rcallon@juniper.net >>>>>>> fenner@research.att.com >>>>>>> sob@harvard.edu >>>>>>> sbrim@cisco.com >>>>>>> mpls@lists.ietf.org >>>>>>> Reponse Contact: tsbsg15@itu.int >>>>>>> Technical Contact: Ghani.Abbas@marconi.com mark.jones@sprint.com >>>>>>> betts01@nortel.com >>>>>>> Purpose: For action >>>>>>> Body: We apologize for not having sent a liaison regarding three >>>>>>> consented Recommendations related to >>>>>>> T-MPLS. The intent of these Recommendations is not to >> change MPLS >>>>>>> but rather to identify a >>>>>>> subset of existing MPLS necessary and sufficient to provide >>>>>>> connection-oriented packet transport. >>>>>>> The approach to the work was to make a profile of the MPLS data >>>>>>> plane functionalities defined in >>>>>>> IETF RFCs using the description of MPLS provided in >> G.8110 (which >>>>>>> was approved last year). >>>>>>> The intended application of this profile is to provide a >>>>>> connection- >>>>>>> oriented packet transport >>>>>>> network. >>>>>>> The focus of the three new recommendations is on the data plane >>>>>>> aspects of T-MPLS. Control plane aspects are currently >> for further >>>>>>> study and the work on this subject is starting. >>>>>>> According to our work methodology the T-MPLS >> definitions are split >>>>>>> into the three main >>>>>>> Recommendations that have been consented in February 2006: >>>>>>> * G.8110.1 dealing with the T-MPLS Architecture >>>>>>> * G.8112 dealing with T-MPLS interface specification >>>>>>> * G.8121 dealing with T-MPLS equipment functional >> specification >>>>>>> A brief high-level introduction of the essential features and >>>>>>> selected options for Transport MPLS >>>>>>> can be found in section 6/G.8110.1. >>>>>>> The objective of the work done by ITU-T SG15 was to define >>>>>> a way to >>>>>>> use MPLS as a connection- >>>>>>> oriented packet-based transport solution for packet aware >>>>>> transport >>>>>>> networks that can support both >>>>>>> packet and circuit (e.g. SDH, OTH or WDM) switching >> technologies >>>>>>> under a common operation, control and management paradigm. For >>>>>>> this purpose T-MPLS deploys the MPLS frame format, >>>>>>> Client to MPLS mapping and MPLS to MPLS multiplexing and >>>>>>> complements this with transport >>>>>>> network OAM (Y.1711), nested connection monitoring requiring the >>>>>>> labels to be present up to the >>>>>>> final node in the network, protection switching (Y.1720/G.8131), >>>>>>> transport network based control >>>>>>> and management planes, maintaining frame ordering and a >> restricted >>>>>>> number of classes of >>>>>>> service/queues. >>>>>>> * MPLS has many applications and it is desirable >> to identify a >>>>>>> subset of MPLS technology that >>>>>>> provides the necessary and sufficient functionality for >> transport >>>>>>> applications. >>>>>>> We have indicated below some of the options we have selected :- >>>>>>> * In IETF RFCs the usage of PHP is optional. We decided >>>>>> not to use >>>>>>> it in order to simplify OAM >>>>>>> procedures >>>>>>> * In IETF RFCs the usage of merging is optional. We >>>>>> decided not to >>>>>>> use it in order to simplify >>>>>>> OAM procedures and also because the relative lower >> number of LSPs >>>>>>> to be supported is not considered a major scaling issue >>>>>>> * The usage of ECMP is optional. We decided not to use it >>>>>> in order >>>>>>> to simplify OAM procedures >>>>>>> * Leaving labels 16-31 for further study was seen >> as a no change >>>>>>> because the label allocation on a >>>> >>>> TOM: Read above. >>>> >>>>>>> link is defined in IETF RFCs as a local matter for any >>>> MPLS device. >>>>>>> We are not expecting that the current version of the >> specification >>>>>>> is going to create any interoperability issue. We envisage two >>>>>>> possible cases of >>>>>>> interoperability: >>>>>>> 1. Interoperability between a T-MPLS box and an >>>> existing full- >>>>>>> featured and fully configurable >>>>>>> MPLS box can be solved by configuring the MPLS box to >> use the same >>>>>>> options selected by T- MPLS (T-MPLS being a profile of >> MPLS this >>>>>>> should be possible). In this case the link between >>>>>>> the two boxes is a T-MPLS link and in the scope of our >>>>>>> Recommendations. >>>>>>> 2. Interoperability between a transport platform >>>>>> supporting T-MPLS >>>>>>> and an existing MPLS box >>>>>>> that uses a different option selection than T-MPLS, should be >>>>>>> solved by the transport platform. In this case the link between >>>>>>> the transport platform and the MPLS box is not a T-MPLS link and >>>>>>> therefore it is outside the scope of T-MPLS >>>>>> recommendations. We are >>>>>>> looking for cooperation >>>>>>> with IETF to develop the detailed specification of this case. >>>>>>> Please find attached the text of the consented Recommendations. >>>>>>> Please note that some minor modifications may be made to these >>>>>>> draft Recommendations as a result of comments made during >>>>>>> the approval process >>>>>>> We will appreciate your comments and suggestions in >>>>>> relation to the >>>>>>> initial scope of T-MPLS as a >>>>>>> packet transport network technology. >>>>>>> We are planning to review your comments during the next meeting >>>>>>> that is planned in Kobe (Japan) on 22-27 April 2006. Results of >>>>>>> the comments will be included into our future work (e.g. >>>>>>> corrigenda or amendments) on T-MPLS Recommendations. >> Amendments of >>>>>>> T-MPLS Recommendations are >>>>>>> already in our plan for the next SG15 plenary meeting >> in November >>>>>>> 2006.We are looking forward >>>>>>> for future cooperation with you in T-MPLS data plane and control >>>>>>> plane evolution. >>>>>>> >>>>>>> Attachments: Consented Text of G.8110.1, G.8112, G.8121 >>>>>>> Attachment(s): >>>>>>> Consented Text of G.8110.1 (https://datatracker.ietf.org/ >>>>>>> documents/LIAISON/file288.zip) >>>>>>> Consented Text of G.8112 (https://datatracker.ietf.org/ >>>>>>> documents/LIAISON/file289.zip) >>>>>>> Consented Text of G.8121 (https://datatracker.ietf.org/ >>>>>>> documents/LIAISON/file290.zip) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>> >>> _______________________________________________ >>> 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@lists.ietf.org Tue Apr 11 12:48:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTM0D-0005UZ-Jb; Tue, 11 Apr 2006 12:46:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTM0C-0005UP-HM for mpls@lists.ietf.org; Tue, 11 Apr 2006 12:46:04 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTM0B-0000lm-Gv for mpls@lists.ietf.org; Tue, 11 Apr 2006 12:46:04 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 17:46:02 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 17:46:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns" Date: Tue, 11 Apr 2006 17:46:01 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353891576CB25@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns" Thread-Index: AcZdg03xnUikHRC6TuqVm1WKHull8AAAVN2Q From: To: X-OriginalArrivalTime: 11 Apr 2006 16:46:02.0099 (UTC) FILETIME=[6AD59C30:01C65D87] X-Spam-Score: 0.2 (/) X-Scan-Signature: 919b3965bd46f7460d234f848680b238 Cc: mpls@lists.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: , Errors-To: mpls-bounces@lists.ietf.org > >> How do you trace the LSP using Y.1711 or is that > >> not an important function for OAM for T-MPLS? Also, from > the IETF's > >> perspective, we have already defined a tool set that > satisfies all of > >> the requirements of ping and trace (tree and > >> path) in a single tool, which is now on the standards track, is > >> widely deployed, and thus should be the tool specified herein. > > > > Tom, tracing in a co-ps mode technology that respects connection > > requirements should be a whole lot easier than in one than does > > not. So > > I would argue that you can re-use the same diagnostic tools=20 > in T-MPLS. >=20 > Theory and practice are very different when it comes > to data plane diagnostics vs. control plane. Hoping that it is easier=20 > and ensuring that it actually works %100 of the time are two quite=20 > different things. NH=3D> If we have a p2p or p2mp connections then all facets of traffic/fault/performance management are definable and tractable. This is not the case with mp2p merging constructs as these don't satisfy connection requirements. This is just a fact. Are you saying this is not true or something? > Also, as someone who > works at a network operator, you surely can appreciate the=20 > advantages of using a single mechanism for fault-detection=20 > and trouble-shooting, especially if it is widely deployed and=20 > available. NH=3D> True, I also appreciate how much easier and cost-effective it is = to operate technologies that respect arch requirements (for their mode) and come originally well-defined functionally (technologies that are either significantly functionally deficient or over-engineered are bad). Not all technologies are equal when it comes to Opex considerations. regards, Neil >=20 > --Tom >=20 >=20 > > BTW - We really should start with a definition of defects including=20 > > entry/exit criteria...everything else builds on this=20 > baseline. Unless=20 > > one has a proper connection however, I really don't see how this is=20 > > possible. > > > > regards, Neil > >> > >> --Tom > >> > >> > >>> -Shahram > >>> > >>>> -----Original Message----- > >>>> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >>>> Sent: Tuesday, April 11, 2006 10:34 AM > >>>> To: Shahram Davari > >>>> Cc: mpls@lists.ietf.org > >>>> Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented=20 > >>>> Recommendatio ns" > >>>> > >>>> > >>>> > >>>>> Hi Tom, > >>>>> > >>>>> 1) Reading the T-MPLS specs I didn't see any specific=20 > label range=20 > >>>>> restriction. Where have you seen this? > >>>> > >>>> See inline marked with "TOM:" > >>>> > >>>>> 2) The OAM specified is for T-MPLS, which as you said is > >> a subset of > >>>>> MPLS. Specifically T-MPLS doesn't include PHP, merging > >> and ECMP as > >>>>> indicated by the Liaison. So why should an OAM that is > >> going to be > >>>>> used for T-MPLS support those functions? > >>>> > >>>> The OAM as specified in the T-MPLS document is not a > >> subset of MPLS; > >>>> it is a completely different mechanism from what is > >> specified at the > >>>> IETF to meet the requirements in RFC4377. As described, > >> y1711 acts on > >>>> a sub-set of MPLS (lets forget about the label range), but > >> does not > >>>> meet all of the requirements as specified in RFC4377, even > >> for this > >>>> subset of MPLS. > >>>> > >>>> --Tom > >>>> > >>>> > >>>> > >>>>> > >>>>> > >>>>> Regards, > >>>>> -Shahram > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >>>>>> Sent: Tuesday, April 11, 2006 9:25 AM > >>>>>> To: mpls@lists.ietf.org > >>>>>> Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented=20 > >>>>>> Recommendations" > >>>>>> > >>>>>> > >>>>>> [Resending to mpls list as I got a warning from the=20 > mailer that=20 > >>>>>> there was a suspicious number of recipients, so I am=20 > not sure it=20 > >>>>>> was delivered.] > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> A few things in the ITU T-MPLS document concern me: > >>>>>> > >>>>>> 1) The document itself constitutes what is essentially > >>>>>> two things: an protocol specification > >>>>>> and an implementation guideline. > >>>>>> > >>>>>> For this reason, I first suggest that=20 > this document > >>>>>> needs to be split into two: one that specifies > >>>>>> the label range allocation (as well as requests > >>>>>> it from the IETF), and a second that specifies > >>>>>> the implementation guideline. I also suggest > >>>>>> removal of "MPLS" from the name. This is very > >>>>>> confusing, and implies that this document is > >>>>>> some new standard for MPLS, whereas what it > >>>>>> really specifies (sans the label range=20 > allocation > >>>>>> and the OAM) is a subset of MPLS functionality. > >>>>>> > >>>>>> 2) With regard to the label range reservation, I am > >>>>>> troubled by this because MPLS has been=20 > widely deployed > >>>>>> without the said reserved label range.=20 > Deployment > >>>>>> of LSRs that suddenly use this special label > >>>>>> range will most likely lead to interoperability > >>>>>> issues. I am also troubled by the lack of > >>>>>> definition of what the reserved labels should > >>>>>> be used for. If in the future, these labels are > >>>>>> defined in a manner that is incompatible with > >>>>>> existing LSRs, this will pose a significant > >>>>>> hurdle to deployments. Again, a=20 > separate document that > >>>>>> requests the label range, as well as specifies > >>>>>> what they are to be used for is appropriate. > >>>>>> > >>>>>> 3) The OAM as specified does not meet the IETF's > >>>>>> requirements for OAM specified in RFC4377. > >>>>>> Y.1711 is not suitable for environments=20 > where PHP is > >>>>>> enabled, and it also has other=20 > deficiencies such as a > >>>>>> lack of tracing functionality, and=20 > cannot handle Equal > >>>>>> Cost Multi-Path (ECMP) LSPs. In=20 > particular, section > >>>>>> 4.3 of RFC4377 stipulates that path=20 > characterization > >>>>>> functions must be able to work in these cases: > >>>>>> > >>>>>> 4.3. Path Characterization > >>>>>> > >>>>>> The path characterization function is the ability=20 > to reveal=20 > >>>>>> details > >>>>>> of LSR forwarding operations. These details can then > >>>> be compared > >>>>>> during subsequent testing relevant to OAM > >> functionality. This > >>>>>> includes but is not limited to: > >>>>>> > >>>>>> - consistent use of pipe or uniform time to live > >>>>>> (TTL) models by > >>>>>> an LSR [RFC3443]. > >>>>>> > >>>>>> - sufficient details that allow the test origin > >> to exercise > >>>>>> all > >>>>>> path permutations related to load spreading > >> (e.g., ECMP). > >>>>>> > >>>>>> - stack operations performed by the LSR, such=20 > as pushes,=20 > >>>>>> pops, > >>>>>> and TTL propagation at penultimate hop LSRs. > >>>>>> > >>>>>> I suggest replacing the reference to Y.1711=20 > with a reference > >>>>>> to rfc4377, rfc4378, and rfc4379. > >>>>>> > >>>>>> --Tom > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Title: T-MPLS Consented Recommendations > >>>>>>> Submission Date: 2006-04-02 > >>>>>>> URL of the IETF Web page: https://datatracker.ietf.org/public/ > >>>>>>> liaison_detail.cgi?detail_id=3D207 > >>>>>>> Please reply by 2006-04-17 > >>>>>>> > >>>>>>> From: Greg Jones(ITU-T SG 15) > >>>>>>> To: IETF MPLS WG, CC: MFA Forum(George Swallow > >>>>>> , > >>>>>>> Loa Andersson ) > >>>>>>> Cc: info@mfaforum.org > >>>>>>> maeda@ansl.ntt.co.jp > >>>>>>> sjtrowbridge@lucent.com > >>>>>>> rcallon@juniper.net > >>>>>>> fenner@research.att.com > >>>>>>> sob@harvard.edu > >>>>>>> sbrim@cisco.com > >>>>>>> mpls@lists.ietf.org > >>>>>>> Reponse Contact: tsbsg15@itu.int > >>>>>>> Technical Contact: Ghani.Abbas@marconi.com=20 > mark.jones@sprint.com=20 > >>>>>>> betts01@nortel.com > >>>>>>> Purpose: For action > >>>>>>> Body: We apologize for not having sent a liaison=20 > regarding three=20 > >>>>>>> consented Recommendations related to T-MPLS. The=20 > intent of these=20 > >>>>>>> Recommendations is not to > >> change MPLS > >>>>>>> but rather to identify a > >>>>>>> subset of existing MPLS necessary and sufficient to provide=20 > >>>>>>> connection-oriented packet transport. The approach to=20 > the work=20 > >>>>>>> was to make a profile of the MPLS data plane functionalities=20 > >>>>>>> defined in IETF RFCs using the description of MPLS provided in > >> G.8110 (which > >>>>>>> was approved last year). > >>>>>>> The intended application of this profile is to provide a > >>>>>> connection- > >>>>>>> oriented packet transport > >>>>>>> network. > >>>>>>> The focus of the three new recommendations is on the=20 > data plane=20 > >>>>>>> aspects of T-MPLS. Control plane aspects are currently > >> for further > >>>>>>> study and the work on this subject is starting.=20 > According to our=20 > >>>>>>> work methodology the T-MPLS > >> definitions are split > >>>>>>> into the three main > >>>>>>> Recommendations that have been consented in February 2006: > >>>>>>> * G.8110.1 dealing with the T-MPLS Architecture > >>>>>>> * G.8112 dealing with T-MPLS interface specification > >>>>>>> * G.8121 dealing with T-MPLS equipment functional > >> specification > >>>>>>> A brief high-level introduction of the essential features and=20 > >>>>>>> selected options for Transport MPLS can be found in section=20 > >>>>>>> 6/G.8110.1. The objective of the work done by ITU-T=20 > SG15 was to=20 > >>>>>>> define > >>>>>> a way to > >>>>>>> use MPLS as a connection- > >>>>>>> oriented packet-based transport solution for packet aware > >>>>>> transport > >>>>>>> networks that can support both > >>>>>>> packet and circuit (e.g. SDH, OTH or WDM) switching > >> technologies > >>>>>>> under a common operation, control and management=20 > paradigm. For=20 > >>>>>>> this purpose T-MPLS deploys the MPLS frame format, Client to=20 > >>>>>>> MPLS mapping and MPLS to MPLS multiplexing and=20 > complements this=20 > >>>>>>> with transport network OAM (Y.1711), nested connection=20 > >>>>>>> monitoring requiring the labels to be present up to the > >>>>>>> final node in the network, protection switching=20 > (Y.1720/G.8131), > >>>>>>> transport network based control > >>>>>>> and management planes, maintaining frame ordering and a > >> restricted > >>>>>>> number of classes of > >>>>>>> service/queues. > >>>>>>> * MPLS has many applications and it is desirable > >> to identify a > >>>>>>> subset of MPLS technology that > >>>>>>> provides the necessary and sufficient functionality for > >> transport > >>>>>>> applications. > >>>>>>> We have indicated below some of the options we have=20 > selected :- > >>>>>>> * In IETF RFCs the usage of PHP is optional. We decided > >>>>>> not to use > >>>>>>> it in order to simplify OAM > >>>>>>> procedures > >>>>>>> * In IETF RFCs the usage of merging is optional. We > >>>>>> decided not to > >>>>>>> use it in order to simplify > >>>>>>> OAM procedures and also because the relative lower > >> number of LSPs > >>>>>>> to be supported is not considered a major scaling issue > >>>>>>> * The usage of ECMP is optional. We decided not to use it > >>>>>> in order > >>>>>>> to simplify OAM procedures > >>>>>>> * Leaving labels 16-31 for further study was seen > >> as a no change > >>>>>>> because the label allocation on a > >>>> > >>>> TOM: Read above. > >>>> > >>>>>>> link is defined in IETF RFCs as a local matter for any > >>>> MPLS device. > >>>>>>> We are not expecting that the current version of the > >> specification > >>>>>>> is going to create any interoperability issue. We=20 > envisage two=20 > >>>>>>> possible cases of > >>>>>>> interoperability: > >>>>>>> 1. Interoperability between a T-MPLS box and an > >>>> existing full- > >>>>>>> featured and fully configurable > >>>>>>> MPLS box can be solved by configuring the MPLS box to > >> use the same > >>>>>>> options selected by T- MPLS (T-MPLS being a profile of > >> MPLS this > >>>>>>> should be possible). In this case the link between > >>>>>>> the two boxes is a T-MPLS link and in the scope of our=20 > >>>>>>> Recommendations. > >>>>>>> 2. Interoperability between a transport platform > >>>>>> supporting T-MPLS > >>>>>>> and an existing MPLS box > >>>>>>> that uses a different option selection than T-MPLS, should be=20 > >>>>>>> solved by the transport platform. In this case the=20 > link between=20 > >>>>>>> the transport platform and the MPLS box is not a=20 > T-MPLS link and=20 > >>>>>>> therefore it is outside the scope of T-MPLS > >>>>>> recommendations. We are > >>>>>>> looking for cooperation > >>>>>>> with IETF to develop the detailed specification of this case.=20 > >>>>>>> Please find attached the text of the consented=20 > Recommendations.=20 > >>>>>>> Please note that some minor modifications may be made=20 > to these=20 > >>>>>>> draft Recommendations as a result of comments made during the=20 > >>>>>>> approval process We will appreciate your comments and=20 > >>>>>>> suggestions in > >>>>>> relation to the > >>>>>>> initial scope of T-MPLS as a > >>>>>>> packet transport network technology. > >>>>>>> We are planning to review your comments during the=20 > next meeting=20 > >>>>>>> that is planned in Kobe (Japan) on 22-27 April 2006.=20 > Results of=20 > >>>>>>> the comments will be included into our future work (e.g.=20 > >>>>>>> corrigenda or amendments) on T-MPLS Recommendations. > >> Amendments of > >>>>>>> T-MPLS Recommendations are > >>>>>>> already in our plan for the next SG15 plenary meeting > >> in November > >>>>>>> 2006.We are looking forward > >>>>>>> for future cooperation with you in T-MPLS data plane=20 > and control=20 > >>>>>>> plane evolution. > >>>>>>> > >>>>>>> Attachments: Consented Text of G.8110.1, G.8112, G.8121 > >>>>>>> Attachment(s): > >>>>>>> Consented Text of G.8110.1 (https://datatracker.ietf.org/ > >>>>>>> documents/LIAISON/file288.zip) > >>>>>>> Consented Text of G.8112 (https://datatracker.ietf.org/ > >>>>>>> documents/LIAISON/file289.zip) > >>>>>>> Consented Text of G.8121 (https://datatracker.ietf.org/ > >>>>>>> documents/LIAISON/file290.zip) > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> mpls mailing list > >>>>>>> mpls@lists.ietf.org=20 > https://www1.ietf.org/mailman/listinfo/mpls > >>>>>> > >>>>>>=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 > >>>> > >>> > >>> _______________________________________________ > >>> 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 > >> >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 13:30:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTMfK-0005lk-SX; Tue, 11 Apr 2006 13:28:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTMfJ-0005lf-NB for mpls@lists.ietf.org; Tue, 11 Apr 2006 13:28:33 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTMfI-0002SL-Ec for mpls@lists.ietf.org; Tue, 11 Apr 2006 13:28:33 -0400 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k3BHSTpX001801; Tue, 11 Apr 2006 12:28:29 -0500 (CDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Apr 2006 13:28:29 -0400 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'neil.2.harrison@bt.com'" , tnadeau@cisco.com Subject: RE: [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns" Date: Tue, 11 Apr 2006 13:28:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: mpls@lists.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: , Errors-To: mpls-bounces@lists.ietf.org > > Tom, > > > > A couple of observations on your remarks: > > > > (i) I agree with you that some clarity is required on > > specific reserved label ranges and their uses. However, I'd > > say it's bigger than just the label ranges and should also > > include how all the header fields (ie S, EXP, TTL) are to be > > used in T-MPLS (I noted you don't think this 'T-MPLS' name is > > good, but I'll stick with it here). Why? Well, folks need > > to consider the various client/server relationships that > > could exist between the various spins of MPLS as-is and > > T-MPLS....and especially misconnectivity between them....so > > how is this going to be handled? > > > > (ii) I'd urge you not to be so hard on Y.1711. This is a > > simple defect detection/handling OAM solution for ANY co-ps > > mode network based on label-swapping that respects the > > architectural requirement of what defines a connection (ie > > single source, connectivity=1). Any form of MPLS that has > > merging (so that is LDP and/or PHP) violates the rules for a > > connection.....this is just a fact.....and so Y.1711 is not > > appropriate (but then attempting to apply any sort of > > determinism across any aspect of traffic/fault/performance > > management is fraught with problems when the rules for > > connections are broken). Neil, Tom, Just curious: you both say that Y.1711 does not work in conjunction with PHP. Why is that? The CV frames have a TTSI vlaue that can be used to identify the source even when because of PHP (and Label Merge) the LSP context is lost. Peter [snipped] _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 13:48:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTMwb-0004Y5-RD; Tue, 11 Apr 2006 13:46:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTMwa-0004Y0-0r for mpls@lists.ietf.org; Tue, 11 Apr 2006 13:46:24 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTMwY-00030Q-Im for mpls@lists.ietf.org; Tue, 11 Apr 2006 13:46:24 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1FTMwU-0007Pf-00 for mpls@lists.ietf.org; Tue, 11 Apr 2006 18:46:18 +0100 Received: from Puppy ([217.158.132.177] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 18:46:53 +0100 Message-ID: <0d8a01c65d8f$e0f9c690$bf849ed9@Puppy> From: "Adrian Farrel" To: "Shahram Davari" , "'Ash, Gerald R \(Jerry\), ALABS'" , "Thomas D. Nadeau" , References: <4B6D09F3B826D411A67300D0B706EFDE024333BD@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns" Date: Tue, 11 Apr 2006 18:42:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 11 Apr 2006 17:46:53.0718 (UTC) FILETIME=[EB5E7360:01C65D8F] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Shahram, Jerry asked about Y.1713 and you said... > My guess: because it is not needed for T-MPLS, since T-MPLS doesn't support label merging (aka LDP). This is really hard for us. We cannot hope to guess what is or is not needed for T-MPLS becuase no-one has seen fit to explain the requirements to us. No: none of the three documents liaised has any discussion of requirements. It all launches straight into feature sets. But one thing the documents *do* say is that protocols are out of scope. So it is entirely possible that LDP would be used in T-MPLS (although I thinik that would be a bad idea!) You should note very clearly that LDP is not synonymous with label merging. Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 13:52:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTN0B-000676-8D; Tue, 11 Apr 2006 13:50:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTN09-000671-8J for mpls@ietf.org; Tue, 11 Apr 2006 13:50:05 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTN09-0003DO-0t for mpls@ietf.org; Tue, 11 Apr 2006 13:50:05 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 11 Apr 2006 13:50:05 -0400 X-IronPort-AV: i="4.04,112,1144036800"; d="scan'208"; a="86211148:sNHT30061144" 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 k3BHo4Wc014978; Tue, 11 Apr 2006 13:50:04 -0400 (EDT) Message-Id: <200604111750.k3BHo4Wc014978@rtp-core-1.cisco.com> To: "Dutta, Pranjal" Subject: Re: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs In-reply-to: Your message of Tue, 11 Apr 2006 10:15:24 +0530. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 11 Apr 2006 13:50:04 -0400 From: Eric Rosen X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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: , Errors-To: mpls-bounces@lists.ietf.org > In Inter-IGP-area or inter-AS case the routes from Rd would be summarized > to Ru and in such a case Ru MAY not find the exact match for such FEC x If I understand your example, Ru has the summary route, Rd has the more specific routes, and Rd is sending Ru label bindings for the more specific routes but not for the summary route. You don't say anything about Ru itself distributing labels bindings for the more specific routes, so presumably the only thing at issue is Ru should label an IP packet that it receives. What will happen is that the IP packet gets sent unlabeled to Rd which then labels it according to the specific route which is the best match to the packet's IP destination address. The label imposition procedure here is: - get the IP destination address - find the prefix in the routing table which is the best match (longest match) for that destination address - use the label which was assigned to that prefix by the LSR which routing says is the next hop for that prefix. It doesn't make sense for Rd to bind labels to prefixes which are more specific than the one in the routing table, as the label imposition procedure will never make use of such labels. I don't think we want to allow LDP to put prefixes in the routing table, or else we'd have to treat it as a second routing algorithm and that would raise all kinds of issues. It is possible though to imagine a different imposition procedure: - get the IP destination address, A - find the prefix, P, in the routing table which is the best match (longest match) for that destination address - get the next hop, N, for P, as specified by routing - if N has distributed any label bindings for prefixes which are longer than P but begin with the same sequence of bits as P, and if any of these, say Q, is a better match for A than P, then use the label which N assigned to Q. This is a complicated procedure, though. You can't just match A against Q, because there might be some prefix R in the routing table, with a different next hop, which is a better match for A than P is, but not as good a match as Q. The above imposition procedure says that the next hop for the packet is determined by the route to R not by the route to P (or Q). It's a complex matter to keep the forwarding tables in proper shape, given that prefixes like Q can come and go asynchronously. There are other complications as well. For example, what do you do if you get a packet which is labeled for Q, but the next hop has changed and the new next hop has not distributed a label for Q? I suppose we could figure all this out if there were an actual problem which didn't have a better solution. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 14:21:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTNT4-0001rh-N4; Tue, 11 Apr 2006 14:19:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTNT3-0001rc-W3 for mpls@lists.ietf.org; Tue, 11 Apr 2006 14:19:57 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTNT3-0004Ap-I2 for mpls@lists.ietf.org; Tue, 11 Apr 2006 14:19:57 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 19:19:56 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 19:19:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] New Liaison Statement, "T-MPLS Consented Recommendations" Date: Tue, 11 Apr 2006 19:19:55 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353891576CBC6@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] New Liaison Statement, "T-MPLS Consented Recommendations" Thread-Index: AcZdjVrnjZjHEssLSVaATCur805EhwAAETBg From: To: , X-OriginalArrivalTime: 11 Apr 2006 18:19:55.0742 (UTC) FILETIME=[88BF4FE0:01C65D94] X-Spam-Score: 0.2 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: mpls@lists.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: , Errors-To: mpls-bounces@lists.ietf.org > > > Tom, > > >=20 > > > A couple of observations on your remarks: > > >=20 > > > (i) I agree with you that some clarity is required on=20 > > > specific reserved label ranges and their uses. However, I'd > > > say it's bigger than just the label ranges and should also=20 > > > include how all the header fields (ie S, EXP, TTL) are to be=20 > > > used in T-MPLS (I noted you don't think this 'T-MPLS' name is=20 > > > good, but I'll stick with it here). Why? Well, folks need=20 > > > to consider the various client/server relationships that=20 > > > could exist between the various spins of MPLS as-is and=20 > > > T-MPLS....and especially misconnectivity between them....so=20 > > > how is this going to be handled? > > >=20 > > > (ii) I'd urge you not to be so hard on Y.1711. This is a=20 > > > simple defect detection/handling OAM solution for ANY co-ps > > > mode network based on label-swapping that respects the=20 > > > architectural requirement of what defines a connection (ie=20 > > > single source, connectivity=3D1). Any form of MPLS that has=20 > > > merging (so that is LDP and/or PHP) violates the rules for a=20 > > > connection.....this is just a fact.....and so Y.1711 is not=20 > > > appropriate (but then attempting to apply any sort of=20 > > > determinism across any aspect of traffic/fault/performance=20 > > > management is fraught with problems when the rules for=20 > > > connections are broken). >=20 >=20 > Neil, Tom, >=20 > Just curious: you both say that Y.1711 does not work in=20 > conjunction with PHP. Why is that? The CV frames have a TTSI=20 > vlaue that can be used to identify the source even when=20 > because of PHP (and Label Merge) the LSP context is lost. >=20 > Peter Hi Peter, good question...let me frame it before giving a specific answer. Co mode networks SHOULD only have p2p and p2mp connections...in fact the definition of a 'connection' is only satisfied by such constructs. Anything else is not a connection and will have various traffic/fault/perf management problems. Correct behaviour is forced in the co-cs mode but is not in the co-ps mode....it's all a function of how the resource-partition labelling works in these 2 modes (can explain in great detail if required). LDP violates this principle by creating SPF merging at arbitrary locations and so does PHP by creating merging on the last hop. PHP also destroys the notion of having the trail termination point in the correct place.=20 OAM should look as much as possible like normal traffic. It should not be proxied by control plane protocols....esp so when noting that in a well-designed co mode network all internal control/management protocols SHOULD be run OOB wrt traffic data-plane. Again this desired behaviour is forced in the co-cs mode due to labelling considerations. Folks can say what they like about the above observations, I stand by them as being correct from a best practice design perspective. So, in a co-ps layer network based on label-swapping an OAM packet SHOULD be identified by a flag in the normal traffic unit header. I wasted a year or so arguing for this several years ago when MPLS had no OAM and folks like Tom were arguing MPLS did not need any OAM at all....things have changed a bit since then. This meant the only way we could provide an indication of an OAM packet was by a special reserved label (value 14, decimal). Bit of a kludge IMO as it means the LSP 'jumps' from having 1 (traffic) label to 2 (traffic+OAM) labels....this is not a very clean behaviour, but it can work OK. Still, that is all that was available due to the design error of not providing for an OAM indicate flag in the original MPLS header. So yes you are right in one sense Peter, this 1-label to 2-label kludge does indeed mean that OAM pkts get sent to (what should be) the trail termination point with PHP. And in the case of a CV packet this has to contain a trail source identifier (TTSI) so yes you can work out where it came from.....does not apply to other OAM packets that do not contain a TTSI. Some advice on this is given in Appendix II to Y.1711.=20 Hardly think it's a glowing example of good design however, this is just a spin-off of the original design error and the subsequent kludge. regards, Neil _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 16:47:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTPjb-0002L5-0Y; Tue, 11 Apr 2006 16:45:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTPja-0002L0-69 for mpls@ietf.org; Tue, 11 Apr 2006 16:45:10 -0400 Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTPjZ-0002Gi-Q5 for mpls@ietf.org; Tue, 11 Apr 2006 16:45:10 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id NAA00647; Tue, 11 Apr 2006 13:45:07 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs Date: Wed, 12 Apr 2006 02:15:06 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs Thread-Index: AcZdc4SPjqaNm3wITr+NR0K1ZKa/7wAMEhwA From: "Dutta, Pranjal" To: "Joel M. Halpern" X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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: , Errors-To: mpls-bounces@lists.ietf.org Thanks for the explanation on this. Let me elaborate a scenario based on the rules that you mentioned. For the procedure of label_map_received we have to apply both the rules 1) and 2) right. For rule one, If Ru gets a label from Rd and Rd is NOT the next hop for the FEC. How Ru decides that the FEC is not next hop are=20 a) FEC exactly matches a route entry but next hop is another LSR or b) As per your rule one FEC matches LPM to a shorter prefix P, and Rd is not next hop for the matched prefix P. Lets say we hit issue b) and due to liberal retention at Ru it retains the label but will not be used for forwarding. Now let's say that routing at Ru changes and now Rd becomes next hop for Prefix P. So now Ru should introduce an entry for the FEC into forwarding table and install the NHLFE entry right? But that violates your Rule 2 then as the exact match condition should be met. If we apply rule 2 now, then we shouldn't use the label from Rd although Rd has become the next hop for Prefix P. Please correct me if I am wrong in this. Regards, Pranjal -----Original Message----- From: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 Sent: Tuesday, 11 April, 2006 7:53 PM To: Dutta, Pranjal Cc: mpls@ietf.org Subject: Re: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs I think that there may be a better way to explain this. There are=20 several different factors at work: 1) A received LDP label MUST NOT be used if the neighbor sending the=20 label is not the next hop for the FEC. This condition does not=20 require an exact match in the forwarding table. 2) A Received label MUST NOT be used for packets which do not match=20 the received FEC. This condition requires an exact match in the=20 forwarding table. This does allow an implementation to create an exact match entry in=20 the forwarding table to select packets that use the label, even if=20 routing provided a shorter prefix. This does allow one to use /32=20 entries without injecting those /32s into the actual routing=20 protocol. However, the most common uses of .LDP (even with /32s)=20 will result in the entries being in the forwarding table anyway. Another way to look at the condition above is that condition 1 is a=20 restriction on the use of a received label advertisement. LPM check=20 is suitable. Condition 2 is a restriction on the contents of the=20 Forwarding-Table-to-Next-hop-label-forwarding-entry that one=20 creates. That must be an exact match. Yours, Joel M. Halpern At 07:02 AM 4/11/2006, Eric W Gray wrote: >The implementation MUST do an exact match, as downstream LSRs will=20 >forward based >only on the label. Because they do not (typically) perform a route=20 >look-up on the label >encapsulated inner IP packet, there is no reason to expect a=20 >downstream LSR to be able >to separate a flow based on longest match when the routes further=20 >downstream are distinct >for "longer matches". > >Dutta, Pranjal wrote: > >> >>Hi Eric, >> As per RFC 3036 Label mapping receive procedures, when Ru >>received a label mapping from Rd for a FEC x, Ru need to find an "exact" >>match of the FEC x(IPv4/V6 prefix) in its route table. In Inter-IGP-area >>or inter-AS case the routes from Rd would be summarized to Ru and in >>such a case Ru MAY not find the exact match for such FEC x. In terms of >>RFC 3036 then Ru MAY not find exact match for the FEC received from Rd >>in its route table and no further action at Ru. My question was why Ru >>can't we do a longest prefix match for the FEC x as LPM means it can be >>reached by a downstream Rd? >> >>Thanks, >>Pranjal > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 17:20:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTQG3-0006km-Vv; Tue, 11 Apr 2006 17:18:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTQG2-0006jQ-1h for mpls@ietf.org; Tue, 11 Apr 2006 17:18:42 -0400 Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTQG1-0003YK-KS for mpls@ietf.org; Tue, 11 Apr 2006 17:18:42 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id OAA03539; Tue, 11 Apr 2006 14:18:37 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs Date: Wed, 12 Apr 2006 02:48:36 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs Thread-Index: AcZdkGLirFEMa8/hTAmT6JbSojIrKQAF+LCg From: "Dutta, Pranjal" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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: , Errors-To: mpls-bounces@lists.ietf.org Hi Eric, Thanks for the detailed explanation. Kindly refer my statements inline. -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com]=20 Sent: Tuesday, 11 April, 2006 11:20 PM To: Dutta, Pranjal Cc: mpls@ietf.org Subject: Re: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs=20 > In Inter-IGP-area or inter-AS case the routes from Rd would be summarized > to Ru and in such a case Ru MAY not find the exact match for such FEC x If I understand your example, Ru has the summary route, Rd has the more specific routes, and Rd is sending Ru label bindings for the more specific routes but not for the summary route. =20 [Pranjal] Yes, that's exactly the scenario of my problem. =20 You don't say anything about Ru itself distributing labels bindings for the more specific routes, so presumably the only thing at issue is Ru should label an IP packet that it receives.=20 [Pranjal] This is the point that I had raised. If there is no exact match in route table, but LPM finds a shorter prefix, Ru should be able to act as ingress LSR for the FEC and should send labeled packets to Rd if its next hop. But should it make a local binding for the same FEC and distribute to Ru's upstream LSRs? As per RFC 3036 we should have an *exact* match else we can't further extend the LSP to upstream. My question was as that since the FEC has matched a LPM prefix P at Ru, why can't Ru consider it for local binding and accordingly adverstise to its upstream LSRs? This condition would arise when Ru and Rd are inter-IGP-Area Border routers or AS border routers. What will happen is that the IP packet gets sent unlabeled to Rd which then labels it according to the specific route which is the best match to the packet's IP destination address. [Pranjal] That means if *exact* match is not found at Ru for the FEC binding from Rd, the label won't be used at all and packets will go to Rd as unlabelled as per RFC 3036. The label imposition procedure here is:=20 - get the IP destination address - find the prefix in the routing table which is the best match (longest match) for that destination address - use the label which was assigned to that prefix by the LSR which routing says is the next hop for that prefix.=20 It doesn't make sense for Rd to bind labels to prefixes which are more specific than the one in the routing table, as the label imposition procedure will never make use of such labels.=20 I don't think we want to allow LDP to put prefixes in the routing table, or else we'd have to treat it as a second routing algorithm and that would raise all kinds of issues. [Pranjal] So, the reason for *exact* match imposition that I could understand is that we don't want routes/prefixes to be added by LDP into FIB. It's the job of routing to manipulate FIBs and here only thing LDP needs to do is to identify entries in FIB to be labeled for downstream LSRs and for local binding accordingly It is possible though to imagine a different imposition procedure:=20 - get the IP destination address, A - find the prefix, P, in the routing table which is the best match (longest match) for that destination address - get the next hop, N, for P, as specified by routing - if N has distributed any label bindings for prefixes which are longer than P but begin with the same sequence of bits as P, and if any of these, say Q, is a better match for A than P, then use the label which N assigned to Q.=20 This is a complicated procedure, though. You can't just match A against Q, because there might be some prefix R in the routing table, with a different next hop, which is a better match for A than P is, but not as good a match as Q. The above imposition procedure says that the next hop for the packet is determined by the route to R not by the route to P (or Q). It's a complex matter to keep the forwarding tables in proper shape, given that prefixes like Q can come and go asynchronously.=20 There are other complications as well. For example, what do you do if you get a packet which is labeled for Q, but the next hop has changed and the new next hop has not distributed a label for Q? =20 [Pranjal] These are the exact issues that I am facing when I consider the FECs based on LPM (against RFC 3036). The problem comes is syncing up the LIB with routing table changes. Especially, the problem is handling an event like "next hop change". In that *exact* match case its easier, we need to see if the entry's next hop has changed. In case of LPM, if the prefix P Itself might have changed/broken up into longer prefixes and that would require LPM match again and complications arise in syncing up ("who is my new prefix P' and its next hop"). I suppose we could figure all this out if there were an actual problem which didn't have a better solution.=20 [Pranjal] Thanks for the detailed case wise explanation. The only thing I see now is that we can't have inter-AS, inter-area LSPs now as routes will be summarized across domains. Regards, Pranjal =20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 18:19:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTRAq-0004zt-TN; Tue, 11 Apr 2006 18:17:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTRAp-0004zo-Ht for mpls@ietf.org; Tue, 11 Apr 2006 18:17:23 -0400 Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTRAp-0006Iy-90 for mpls@ietf.org; Tue, 11 Apr 2006 18:17:23 -0400 Received: from user-2ivf9b8.dialup.mindspring.com ([165.247.165.104] helo=JMHLap3.stevecrocker.com) by pop-sarus.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1FTRAi-0000Dv-00; Tue, 11 Apr 2006 18:17:17 -0400 Message-Id: <7.0.1.0.0.20060411181324.032bc318@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 11 Apr 2006 18:17:10 -0400 To: "Dutta, Pranjal" From: "Joel M. Halpern" Subject: RE: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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: , Errors-To: mpls-bounces@lists.ietf.org The basic question is how much complication an implementation wishes to undertake to allow for the mismatch. Note that such mismatches are rare. As a local matter, an implementation can chose to create the FTN entry for the exact match, and keep track of the relationship between that entry and the actual routing entry. Eric has argued that such is undesirable complication. I would tend to agree with him in the abstract. What you choose to do in your implementation may depend upon your structures and on what problems you confront in the field. Creating the local entries and using them is legal. Such entries would not affect routing advertisements. They probably don't even effect label advertisements. Yours, Joel M. Halpern At 04:45 PM 4/11/2006, Dutta, Pranjal wrote: >Thanks for the explanation on this. > >Let me elaborate a scenario based on the rules that you mentioned. > >For the procedure of label_map_received we have to apply both the rules >1) and 2) right. For rule one, If Ru gets a label from Rd and Rd is NOT >the next hop for the FEC. How Ru decides that the FEC is not next hop >are >a) FEC exactly matches a route entry but next hop is another LSR or b) >As per your rule one FEC matches LPM to a shorter prefix P, and Rd is >not next hop for the matched prefix P. Lets say we hit issue b) and due >to liberal retention at Ru it retains the label but will not be used for >forwarding. > >Now let's say that routing at Ru changes and now Rd becomes next hop for >Prefix P. So now Ru should introduce an entry for the FEC into >forwarding table and install the NHLFE entry right? But that violates >your Rule 2 then >as the exact match condition should be met. If we apply rule 2 now, then >we shouldn't use the label from Rd although Rd has become the next hop >for Prefix P. Please correct me if I am wrong in this. > >Regards, >Pranjal > >-----Original Message----- >From: Joel M. Halpern [mailto:joel@stevecrocker.com] >Sent: Tuesday, 11 April, 2006 7:53 PM >To: Dutta, Pranjal >Cc: mpls@ietf.org >Subject: Re: [mpls] One LDP Implementation specific question of receive >label mapping for prefix FECs > >I think that there may be a better way to explain this. There are >several different factors at work: > >1) A received LDP label MUST NOT be used if the neighbor sending the >label is not the next hop for the FEC. This condition does not >require an exact match in the forwarding table. >2) A Received label MUST NOT be used for packets which do not match >the received FEC. This condition requires an exact match in the >forwarding table. > >This does allow an implementation to create an exact match entry in >the forwarding table to select packets that use the label, even if >routing provided a shorter prefix. This does allow one to use /32 >entries without injecting those /32s into the actual routing >protocol. However, the most common uses of .LDP (even with /32s) >will result in the entries being in the forwarding table anyway. > >Another way to look at the condition above is that condition 1 is a >restriction on the use of a received label advertisement. LPM check >is suitable. Condition 2 is a restriction on the contents of the >Forwarding-Table-to-Next-hop-label-forwarding-entry that one >creates. That must be an exact match. > >Yours, >Joel M. Halpern > >At 07:02 AM 4/11/2006, Eric W Gray wrote: > >The implementation MUST do an exact match, as downstream LSRs will > >forward based > >only on the label. Because they do not (typically) perform a route > >look-up on the label > >encapsulated inner IP packet, there is no reason to expect a > >downstream LSR to be able > >to separate a flow based on longest match when the routes further > >downstream are distinct > >for "longer matches". > > > >Dutta, Pranjal wrote: > > > >> > >>Hi Eric, > >> As per RFC 3036 Label mapping receive procedures, when Ru > >>received a label mapping from Rd for a FEC x, Ru need to find an >"exact" > >>match of the FEC x(IPv4/V6 prefix) in its route table. In >Inter-IGP-area > >>or inter-AS case the routes from Rd would be summarized to Ru and in > >>such a case Ru MAY not find the exact match for such FEC x. In terms >of > >>RFC 3036 then Ru MAY not find exact match for the FEC received from Rd > >>in its route table and no further action at Ru. My question was why Ru > >>can't we do a longest prefix match for the FEC x as LPM means it can >be > >>reached by a downstream Rd? > >> > >>Thanks, > >>Pranjal > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 11 18:25:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTRGf-0007aL-D8; Tue, 11 Apr 2006 18:23:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTRGd-0007aG-96 for mpls@lists.ietf.org; Tue, 11 Apr 2006 18:23:23 -0400 Received: from mx4.tellabs.com ([204.154.129.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTRGd-0006kj-18 for mpls@lists.ietf.org; Tue, 11 Apr 2006 18:23:23 -0400 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 11 Apr 2006 22:23:22 +0000 X-SBRS: None X-IronPort-AV: i="4.04,113,1144022400"; d="scan'208"; a="50018446:sNHT261321964" Received: from USNVEX1.tellabs-west.tellabsinc.net ([172.23.216.101]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 11 Apr 2006 17:23:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns" Date: Tue, 11 Apr 2006 17:24:44 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns" Thread-Index: AcZdj+i35VcnC8jxQTSqIOnSVmys8AAJN/Pg From: "Mack-Crane, T. Benjamin" To: "Adrian Farrel" , "Shahram Davari" , "Ash, Gerald R \(Jerry\), ALABS" , "Thomas D. Nadeau" , X-OriginalArrivalTime: 11 Apr 2006 22:23:22.0170 (UTC) FILETIME=[8ADB59A0:01C65DB6] Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Adrian, I agree that the requirements do not seem to be clear to everyone participating in this discussion. G.8110.1 does state "Transport MPLS is a connection-oriented packet switched transport layer network technology based on MPLS technology" which says a lot to folks familiar with transport network architectures and functional modeling of layer networks. I understand this may not be clear to others however. Perhaps one good way to think about T-MPLS is as an alternative to TDM transport. An LSR will relate to a T-MPLS transport device in a manner similar to the way it relates to a SONET or SDH transport device, and T-MPLS will provide transport services similar to those provided by SONET/SDH. From this perspective it may be easier to understand the functional subset selected for T-MPLS. Regards, Ben > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, April 11, 2006 12:42 PM > To: Shahram Davari; 'Ash, Gerald R (Jerry), ALABS'; Thomas D. Nadeau; > mpls@lists.ietf.org > Subject: Re: [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio > ns" >=20 > Shahram, >=20 > Jerry asked about Y.1713 and you said... >=20 > > My guess: because it is not needed for T-MPLS, since T-MPLS doesn't > support label merging (aka LDP). >=20 > This is really hard for us. > We cannot hope to guess what is or is not needed for T-MPLS becuase no-one > has seen fit to explain the requirements to us. > No: none of the three documents liaised has any discussion of > requirements. It all launches straight into feature sets. >=20 > But one thing the documents *do* say is that protocols are out of scope. > So it is entirely possible that LDP would be used in T-MPLS (although I > thinik that would be a bad idea!) >=20 > You should note very clearly that LDP is not synonymous with label > merging. >=20 > Adrian >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Apr 12 05:54:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTc1D-0002ta-PO; Wed, 12 Apr 2006 05:52:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTc1C-0002sZ-2T for mpls@lists.ietf.org; Wed, 12 Apr 2006 05:52:10 -0400 Received: from smtpmast05.marconi.com ([128.87.251.114]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTc1A-0006NT-NG for mpls@lists.ietf.org; Wed, 12 Apr 2006 05:52:10 -0400 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpmast05.marconi.com (8.12.11.20060308/8.12.11) with ESMTP id k3C9q3KB000758 for ; Wed, 12 Apr 2006 10:52:07 +0100 (BST) (envelope-from Diego.Caviglia@marconi.com) Sensitivity: To: mpls@lists.ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Wed, 12 Apr 2006 11:51:31 +0200 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(Release 5.0.13a |April 8, 2004) at 12/04/2006 10:52:06 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [mpls] T-MPLS comments 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: , Errors-To: mpls-bounces@lists.ietf.org A couple of quick comment to the T-MPLS specs. G.8110.1 "Bidirectional LSPs are supported by associating two unidirectional LSPs in the data plane" [dc] This sentence seems to exclude the possibility to have a simmetric bi-directional LSP. If GMPLS is used as a control plane for T-MPLS should be good to include the possibility to have simmetric bidirectional LSPs given that GMPLS support the set-up of that kind of circuits. Moreover having a single 5-tuple identifiyng a bidirectional LSP simplify the maintenence of bi-dicectional circuits. "Both global and per interface label space are supported" [dc] RFC 3031 defines the two kind of label scope as: 1 per-interface label space 2 per-platform label space. I think that the definition of 3031 should be also used in G.8110.1, given that the term global is misleading. Regards Diego _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Apr 12 08:18:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTeGd-00065s-7A; Wed, 12 Apr 2006 08:16:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTeG9-00052X-FW for mpls@ietf.org; Wed, 12 Apr 2006 08:15:45 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTdwo-0002Ie-1C for mpls@ietf.org; Wed, 12 Apr 2006 07:55:46 -0400 Received: from imo-d02.mx.aol.com ([205.188.157.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FTdms-000225-S3 for mpls@ietf.org; Wed, 12 Apr 2006 07:45:32 -0400 Received: from ewgray2k@netscape.net by imo-d02.mx.aol.com (mail_out_v38_r7.3.) id 6.1b.149574b0 (22680); Wed, 12 Apr 2006 07:45:11 -0400 (EDT) Received: from [192.168.3.101] (c-24-128-207-21.hsd1.nh.comcast.net [24.128.207.21]) by air-in04.mx.aol.com (v108_r3.6) with ESMTP id MAILININ41-5898443ce8471bc; Wed, 12 Apr 2006 07:45:11 -0500 Message-ID: <443CE824.9090300@netscape.net> Date: Wed, 12 Apr 2006 07:44:36 -0400 From: Eric W Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs References: <443B8CA8.50806@netscape.net> <7.0.1.0.0.20060411101634.03689c90@stevecrocker.com> In-Reply-To: <7.0.1.0.0.20060411101634.03689c90@stevecrocker.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 24.128.207.21 X-Mailer: Unknown (No Version) X-Spam-Flag: NO X-Spam-Score: -2.6 (--) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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: , Errors-To: mpls-bounces@lists.ietf.org Joel, What you're saying is true, but it is the answer to a different question. -- Eric Joel M. Halpern wrote: > I think that there may be a better way to explain this. There are > several different factors at work: > > 1) A received LDP label MUST NOT be used if the neighbor sending the > label is not the next hop for the FEC. This condition does not > require an exact match in the forwarding table. > 2) A Received label MUST NOT be used for packets which do not match > the received FEC. This condition requires an exact match in the > forwarding table. > > This does allow an implementation to create an exact match entry in > the forwarding table to select packets that use the label, even if > routing provided a shorter prefix. This does allow one to use /32 > entries without injecting those /32s into the actual routing > protocol. However, the most common uses of .LDP (even with /32s) will > result in the entries being in the forwarding table anyway. > > Another way to look at the condition above is that condition 1 is a > restriction on the use of a received label advertisement. LPM check > is suitable. Condition 2 is a restriction on the contents of the > Forwarding-Table-to-Next-hop-label-forwarding-entry that one creates. > That must be an exact match. > > Yours, > Joel M. Halpern > > At 07:02 AM 4/11/2006, Eric W Gray wrote: > >> The implementation MUST do an exact match, as downstream LSRs will >> forward based >> only on the label. Because they do not (typically) perform a route >> look-up on the label >> encapsulated inner IP packet, there is no reason to expect a >> downstream LSR to be able >> to separate a flow based on longest match when the routes further >> downstream are distinct >> for "longer matches". >> >> Dutta, Pranjal wrote: >> >>> >>> Hi Eric, >>> As per RFC 3036 Label mapping receive procedures, when Ru >>> received a label mapping from Rd for a FEC x, Ru need to find an >>> "exact" >>> match of the FEC x(IPv4/V6 prefix) in its route table. In >>> Inter-IGP-area >>> or inter-AS case the routes from Rd would be summarized to Ru and in >>> such a case Ru MAY not find the exact match for such FEC x. In terms of >>> RFC 3036 then Ru MAY not find exact match for the FEC received from Rd >>> in its route table and no further action at Ru. My question was why Ru >>> can't we do a longest prefix match for the FEC x as LPM means it can be >>> reached by a downstream Rd? >>> >>> Thanks, >>> Pranjal >> >> > > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Apr 12 12:36:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTiII-0007Jj-L8; Wed, 12 Apr 2006 12:34:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTiIH-0007Je-B0 for mpls@ietf.org; Wed, 12 Apr 2006 12:34:13 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=oberon.imc.kth.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTiIG-00041x-EK for mpls@ietf.org; Wed, 12 Apr 2006 12:34:13 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id k3CGOJWT002064 for ; Wed, 12 Apr 2006 18:24:19 +0200 Received: from [127.0.0.1] ([172.16.2.231]) by mail1.imc.kth.se; Wed, 12 Apr 2006 18:33:18 +0200 Message-ID: <443D2BCB.2000209@pi.se> Date: Wed, 12 Apr 2006 18:33:15 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: multipart/mixed; boundary="------------080107080603000806020200" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4f585e1bcd209294c6b9386034cecfc6 Cc: Subject: [mpls] draft working group minutes from Dallas 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: , Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --------------080107080603000806020200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, the working group minutes from Dallas. Thanks to Giles and Tom who took note, they are the reason anything got captured. However, mis- spellings, curious grammar and misunderstandings are mine. Please comment to the wg co-chairs and or the list. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se --------------080107080603000806020200 Content-Type: text/plain; name="mpls-minutes-dallas.txt" Content-Disposition: inline; filename="mpls-minutes-dallas.txt" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by oberon.imc.kth.se id k3CGOJWT002064 Minutes form MPLS WG meeting at the IEYF65 in Dallas =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Monday, March 20, 2006, 9.00 - 11.30 AM 1. Agenda bashing ----------------- Agenda adopted as presented. 2. Working group status ----------------------- As of this meeting we have a new Area Director for the Routing Area,=20 Ross Callon. We welcome Ross and thanks Alex for the last for four=20 years. A good MPLS status page could be found at: http://www1.tools.ietf.org/wg/mpls/ apart from document status it is possible to find also agendas and=20 There are five new RFCs since the last meeting: RFC 4379 (LSP ping) RFC 4378 (OAM Framwork) RFC 4377 (OAM Requirements) RFC 4220 (TE Link MIB) RFC 4221 (Management Overview) =20 There is also a non working group RFC: RFC 4381 (Informational) Title: Analysis of the Security of=20 BGP/MPLS IP Virtual Private Networks (VPNs) M. Behringer that should be interesting reading for the working group. The following documents are the in RFC-ed Queue: ------------------------------------------------ - draft-ietf-mpls-bgp-mpls-restart-05, for this draft there is a=20 dependency to a document in the Inter Domain Routing (idr) working group. - draft-ietf-mpls-p2mp-sig-requirement-04, for this draft there is=20 no obvious unresolved issues, and it should be published soon. The following documents are in IESG review: ------------------------------------------ The three drafts in the package to take LDP to Draft Standards: - draft-ietf-mpls-ldp-experience-00.txt - draft-ietf-mpls-ldp-survey2002-00.txt - draft-ietf-mpls-rfc3036bis-03.txt --------------------------------------- Alex reported from the IESG review. There are issues in that the=20 IETF Standards Process (RFC 2999) says that a normative reference in a Draft Standard can't point to a document that is "only" a Proposed=20 Standard. The LDP specification is dependent on the MPLS=20 Architecture (RFC 3031) that is still Proposed Standard. The suggested remedy here is to included enough of the of the=20 information that is reference directly in the LDP specification and then move the reference to Informational. There were discussion about the this, but also stated that the MPLS=20 working group is not the venue for this discussion, should be taken=20 to newtrk.=20 - draft-ietf-mpls-ecmp-bcp-02.txt --------------------------------- This draft is also in IESG evaluation. There is a "discuss" in the=20 review that has not been solved. George will meet with Margaret=20 Wasserman to try to solve the problem this week. As soon as the=20 discuss is resovled a new draft with be published, - draft-ietf-mpls-nodeid-subobject-07.txt ----------------------------------------- This document has been approved by the IESG and announced, but has=20 not yet shown up in the RFC-Editors queue. Working group drafts: --------------------- The draft that will be on the agenda later is not reiterated here. =09 draft-ietf-mpls-icmp-04 ----------------------- This drafts has a dependency on a draft progressed in the Internet Area, that draft will be on the Internet Area agenda this week. Ron will be back with further information as soon as we have the outcome of the discussion in Internet Area. draft-ietf-mpls-lsr-self-test-06 -------------------------------- The LSP Ping has been approved, so the LSR Self Test is now ready=20 to be sent to the IESG for review. draft-ietf-mpls-multicast-encaps-00 ----------------------------------- No news this time draft-ietf-mpls-over-l2tpv3-01 ------------------------------ The draft has been republished and is ready for Working Group Last=20 call. draft-ietf-mpls-p2mp-lsp-ping-00 -------------------------------- This draft has been waiting on multicast LDP to stabilize. The issue has been whether to put TE and LDP in the same draft or not. Authors want to discuss with the multicast LDP authors during this week to reach an agreement. draft-ietf-mpls-p2mp-oam-reqs-01 -------------------------------- There were useful comments on list on the earlier draft, it has been respun. The authors think it is ready for working last call. draft-ietf-mpls-soft-preemption-07 ---------------------------------- This draft has a dependency on a yet unpublished BCP, J-P has=20 promised to start the process to get this BCP moving. draft-ietf-mpls-upstream-label-00 ---------------------------------=09 No news. "Un-published" working group drafts ---------------------------------- draft-raggarwa-mpls-ldp-upstream-00 has been accepted as a=20 working group draft and will be published after the IETF meeting. Other than that - no news. "Dated draft" working group drafts ---------------------------------- draft-ietf-mpls-fastreroute-mib-04 has expired, Tom has taken the initiative to republish and finalize this draft. 3. MPLS traffic engineering --------------------------- draft-vasseur-mpls-number-0-bw-te-lsps-00 ----------------------------------------- The problem addressed in this draft is balancing trafffic across=20 multiple ECMPs. Currently non-zero b/w LSPs balance OK the 0 b/w=20 ones don't. To re-optimise one need to know how many 0 b/w LSPs one have per link. Currently there is no knowledge of this in OSPF-TE or ISIS-TE so one can't just run a CSPF. Proposal is a new sub-TLV that just advertises the number of=20 zero-b/w LSPs on each link. There is no changes in the flooding procedure involved and no IGP=20 scaling impact. This is a very simple solution, to a very real=20 problem. Working group chairs pointed out that this proposes changes to OSPF and ISIS. It should be taken to those WGs after we agreed that it is=20 a requirement? draft-ietf-mpls-explicit-resource-control-bundle-01 --------------------------------------------------- No one of the authors were present. This item was deferred. draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01 ------------------------------------------------- Kohei Shiomoto This draft is intended for the CCAMP working group presented here for information and to solicit feedback.=20 The draft discusses migration requirements, models, and scenarios for a migration from an MPLS-TE to an GMPLS control plane. For the migration period four interworking scenarios has been identified: 1) MPLS->GMPLS->MPLS 2) GMPLS->MPLS-GMPLS 3) GMPLS->MPLS 4) MPLS->GMPLS In the first two cases the ingress and egress LSRs are in the same technology domain. There are two major areas that need more work - signalling and=20 routing. To achieve the migration goal we need to pay special=20 attention to differences how these are treated in the MPLS and GMPLS domain. The problems are mostly identified and the next step is to is to figure out which solution directions we should take. =20 Feedback and comments from the MPLS working group is appreciated. draft-yasukawa-mpls-scaling-analysis-00 draft-yasukawa-mpls-mp2p-rsvpte-00 --------------------------------------- Seisho The drafts discusses MPLS scaling issues given larger MPLS P2P=20 networks, if a large number of PEs need to be fully meshed this generates a huge number of LSPs in the core. The draft looks at=20 different scaling limitations, e.g. memory, processing and=20 management. Memory is not seen as a real problem, the processing issues might be for e.g. soft-state, protocols, the impact of a large number of=20 LSPs on Network Management Systems (NMS) could be drastic. The draft discusses three possible strategies to address these scaling issues, P2P tunnels in the core, LSP hierarchy and MP2P LSPs. P2P tunnels gives god scaling in the core, LSP hierarchy is most=20 effective towards the edge, while MP2P LSPs is effective near the=20 egress, but have no impact near the ingress. Next step will be continued analysis of scaling issues, to determine real network sizes and limitations. A requirements draft will be=20 written, and work with implementers is planned. JP commented that this is very interesting and promising as far as it goes. However there are issus that in to be addressed. These=20 issues are e.g. sizing of core tunnels, fast re-route and protection of hierachical LSps will reduce the benefits. JP offered to work=20 with the authors to cover these issues. This draft is intended to become an Informational RFC. 4. MPLS p2MP ------------ P2MP LDP requirements draft-leroux-mpls-mp-ldp-reqs-03 -------------------------------- Jean-Louis Changes since previous version - solution oriented requirements and=20 text that said that a multicast routing prtocol should not be=20 required been removed. A "complexity requirement" has been added saying that additional=20 routing protocol should not be required in the core. Requirements on avoiding replication on LAN interfaces has been=20 clarified. A branch LSR must be able to send one copy on a LAN to=20 reach multiple downstream LSRs. It must be possible to select a=20 single upstream LSR on a LAN for one P2MP LSP and it shall be=20 possible to load balance between candidate upstream LSRs. The draft is now quite stable, but needs working group feedback.=20 There are some comments (mostly editorial) that will be included in the next version.=20 There is a growing support to make this a working group document, working group chairs will take this to the mailing list. draft-ietf-mpls-ldp-p2mp-00 --------------------------- Ice This draft is the outcome of merging to earlier drafts from Ina and Ice. It is now a working group document. Changes since the earlier individual version - references to the=20 upstream label allocation drafts has been added. =20 There is some future work needed: - resolve issues of ECMP upstream LSR selection - minimize packet loss during upstream LSR change=20 (make before break?) draft-ietf-mpls-rsvp-te-p2mp-03 ------------------------------- Dimitri Some point has been discussed over the last couple of weeks, it is time to wrap up. - document how to protect against branch failure, there are three=20 alternatives a. include the simple cases in the current draft and leave the rest to another draft b. take the whole issue to a separate draft c. postpone publication until we have solved this issue No one is arguing for option c, and we seems to be converging on=20 option b. There is also a proposed a clean-up of the terminology. Version 4 will be ready to publish end of April and should be the draft we take to working group last call. Reroute Extensions to LDP for P2MP LSP draft-liu-mpls-ldp-p2mp-reroute-00.txt -------------------------------------- Shuying Liu The goal of this draft is to reduce disruption and duplication during rerouting. The rerouting mechanism in draft-ietf-mpls-ldp-p2mp has issues in terms of LSR load, traffic disruption and scaling. A new mechanism which reduces disruption time and data duplication is proposed. Working group chairs pointed out that there is already a working group document that potentially will address these issues (draft-ietf-mpls-ldp-p2mp-00). The two group a=F3f authors should discuss and see if it is possible to merge these ideas into the working group documents. 7. T-MPLS; report from the IETF liaison to ITU-T SG15 ----------------------------------------------------- Transport MPLS Adrian Adrian very carefully pointed out that he was reporting on an=20 activity within the ITU-T Q12/15 for information.=20 "Don't shot the messenger". Q12/15 is currently working on something that they say is a profile (subset) of MPLS, i.e. Transport MPLS (T-MPLS). The first round of the documents are already decided (consented) on or close to being=20 decided on. The is a T-MPLS Architecture document (G.8110.1) consented in=20 February 2006. This document describe the MPLS for a transport=20 environment and what functional units are needed to provide that. There are certain parts of the text in the documents that, even=20 though positioning T-MPLS as a subset of MPLS, needs to be looked into for compatibility reason. It is clear that this should have been liaised from Q12/15 to the MPLS working group. The working group chairs will send a liaison to SG 15 and point this out and also request that the documents are liaised to us. 8. RSVP-TE extensions --------------------- draft-xu-mpls-rsvp-te-bidirection-00 ------------------------------------ Xiaohu Xu By the binding of two unidirectional RSVP-TE tunnels between a pair of LSRs, a bidirectional RSVP-E tunnel could be formed. The=20 bidirectional RSVP-TE tunnel can be used e.g. to establish L3VPN=20 with virtual router technology. =20 It was decided to take this discussion to the working group mailing- list. 9. End of meeting --------------080107080603000806020200 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 --------------080107080603000806020200-- From mpls-bounces@lists.ietf.org Wed Apr 12 12:51:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTiWm-0006Cb-8C; Wed, 12 Apr 2006 12:49:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTiWk-0006CW-Cf for mpls@ietf.org; Wed, 12 Apr 2006 12:49:10 -0400 Received: from imo-d01.mx.aol.com ([205.188.157.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTiWk-0004TD-0i for mpls@ietf.org; Wed, 12 Apr 2006 12:49:10 -0400 Received: from ewgray2k@netscape.net by imo-d01.mx.aol.com (mail_out_v38_r7.3.) id 6.1b0.117f6352 (22681); Wed, 12 Apr 2006 12:48:44 -0400 (EDT) Received: from [192.168.3.101] (c-24-128-207-21.hsd1.nh.comcast.net [24.128.207.21]) by air-in04.mx.aol.com (v108_r3.6) with ESMTP id MAILININ42-5899443d2f6c7a; Wed, 12 Apr 2006 12:48:44 -0400 Message-ID: <443D2F45.3070605@netscape.net> Date: Wed, 12 Apr 2006 12:48:05 -0400 From: Eric W Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs References: <7.0.1.0.0.20060411181324.032bc318@stevecrocker.com> In-Reply-To: <7.0.1.0.0.20060411181324.032bc318@stevecrocker.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 24.128.207.21 X-Mailer: Unknown (No Version) X-Spam-Flag: NO X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 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: , Errors-To: mpls-bounces@lists.ietf.org If I understand the problem under discussion correctly, this is the basic scenario: LSR-1 (Ru) -----> LSR-2 (Rd) The initial question was related to how LSR-1 handles a label mapping received (presumably in downstream unsolicited label advertisement mode) from LSR-2, for a FEC corresponding to an aggregate route (e.g. - 10.1.0.0/16) - if LSR-1 does not have an exact match route entry. Assuming that both LSRs are functioning properly and LSR-2 is using LDP to send unsolicited label mappings for FECs that correspond to routes it has advertised, it is unlikely that this situation will arise. LSR-1 would only receive label mappings - from LSR-2 - for routes it (LSR-1) knows of (also from LSR-2 - at least). An implementor might decide to incorporate a delay prior to making this check, in order to eliminate some potential race conditions. And implementors may disagree as to what it means for LSR-1 to have an entry. But - bottom line - if the check for an exact match between FEC and route entry finds that such an entry does not exist in an LSR, the corresponding label must not be used. The procedures for handling label mappings are - in part - intended to provide for robustness in the event that another LSR is not functioning properly. Much of the discussion surrounding this question has been about complex things an implementation might do. None of these things are fundamentally incompatible with the procedures as written. -- Eric Joel M. Halpern wrote: > The basic question is how much complication an implementation wishes > to undertake to allow for the mismatch. > Note that such mismatches are rare. > > As a local matter, an implementation can chose to create the FTN entry > for the exact match, and keep track of the relationship between that > entry and the actual routing entry. Eric has argued that such is > undesirable complication. I would tend to agree with him in the > abstract. What you choose to do in your implementation may depend > upon your structures and on what problems you confront in the field. > Creating the local entries and using them is legal. Such entries > would not affect routing advertisements. They probably don't even > effect label advertisements. > > Yours, > Joel M. Halpern > > At 04:45 PM 4/11/2006, Dutta, Pranjal wrote: > >> Thanks for the explanation on this. >> >> Let me elaborate a scenario based on the rules that you mentioned. >> >> For the procedure of label_map_received we have to apply both the rules >> 1) and 2) right. For rule one, If Ru gets a label from Rd and Rd is NOT >> the next hop for the FEC. How Ru decides that the FEC is not next hop >> are >> a) FEC exactly matches a route entry but next hop is another LSR or b) >> As per your rule one FEC matches LPM to a shorter prefix P, and Rd is >> not next hop for the matched prefix P. Lets say we hit issue b) and due >> to liberal retention at Ru it retains the label but will not be used for >> forwarding. >> >> Now let's say that routing at Ru changes and now Rd becomes next hop for >> Prefix P. So now Ru should introduce an entry for the FEC into >> forwarding table and install the NHLFE entry right? But that violates >> your Rule 2 then >> as the exact match condition should be met. If we apply rule 2 now, then >> we shouldn't use the label from Rd although Rd has become the next hop >> for Prefix P. Please correct me if I am wrong in this. >> >> Regards, >> Pranjal >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:joel@stevecrocker.com] >> Sent: Tuesday, 11 April, 2006 7:53 PM >> To: Dutta, Pranjal >> Cc: mpls@ietf.org >> Subject: Re: [mpls] One LDP Implementation specific question of receive >> label mapping for prefix FECs >> >> I think that there may be a better way to explain this. There are >> several different factors at work: >> >> 1) A received LDP label MUST NOT be used if the neighbor sending the >> label is not the next hop for the FEC. This condition does not >> require an exact match in the forwarding table. >> 2) A Received label MUST NOT be used for packets which do not match >> the received FEC. This condition requires an exact match in the >> forwarding table. >> >> This does allow an implementation to create an exact match entry in >> the forwarding table to select packets that use the label, even if >> routing provided a shorter prefix. This does allow one to use /32 >> entries without injecting those /32s into the actual routing >> protocol. However, the most common uses of .LDP (even with /32s) >> will result in the entries being in the forwarding table anyway. >> >> Another way to look at the condition above is that condition 1 is a >> restriction on the use of a received label advertisement. LPM check >> is suitable. Condition 2 is a restriction on the contents of the >> Forwarding-Table-to-Next-hop-label-forwarding-entry that one >> creates. That must be an exact match. >> >> Yours, >> Joel M. Halpern >> >> At 07:02 AM 4/11/2006, Eric W Gray wrote: >> >The implementation MUST do an exact match, as downstream LSRs will >> >forward based >> >only on the label. Because they do not (typically) perform a route >> >look-up on the label >> >encapsulated inner IP packet, there is no reason to expect a >> >downstream LSR to be able >> >to separate a flow based on longest match when the routes further >> >downstream are distinct >> >for "longer matches". >> > >> >Dutta, Pranjal wrote: >> > >> >> >> >>Hi Eric, >> >> As per RFC 3036 Label mapping receive procedures, when Ru >> >>received a label mapping from Rd for a FEC x, Ru need to find an >> "exact" >> >>match of the FEC x(IPv4/V6 prefix) in its route table. In >> Inter-IGP-area >> >>or inter-AS case the routes from Rd would be summarized to Ru and in >> >>such a case Ru MAY not find the exact match for such FEC x. In terms >> of >> >>RFC 3036 then Ru MAY not find exact match for the FEC received from Rd >> >>in its route table and no further action at Ru. My question was why Ru >> >>can't we do a longest prefix match for the FEC x as LPM means it can >> be >> >>reached by a downstream Rd? >> >> >> >>Thanks, >> >>Pranjal >> > > > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Apr 12 13:04:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTijs-0004d5-6f; Wed, 12 Apr 2006 13:02:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTijr-0004d0-6g for mpls@ietf.org; Wed, 12 Apr 2006 13:02:43 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTijp-00057K-WF for mpls@ietf.org; Wed, 12 Apr 2006 13:02:43 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 12 Apr 2006 10:02:42 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,115,1144047600"; d="scan'208"; a="25752432:sNHT21814384" 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 k3CH2fTL010801; Wed, 12 Apr 2006 13:02:41 -0400 (EDT) Message-Id: <200604121702.k3CH2fTL010801@rtp-core-1.cisco.com> To: Loa Andersson Subject: Re: [mpls] draft working group minutes from Dallas In-reply-to: Your message of Wed, 12 Apr 2006 18:33:15 +0200. <443D2BCB.2000209@pi.se> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Wed, 12 Apr 2006 13:02:41 -0400 From: Eric Rosen X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org These minutes are so selective in what they include and what they omit that I think it would be better to have no minutes at all than to leave these as the official record of the meeting. > There are issues in that the IETF Standards Process (RFC 2999) says that > a normative reference in a Draft Standard can't point to a document that > is "only" a Proposed Standard. The LDP specification is dependent on the > MPLS Architecture (RFC 3031) that is still Proposed Standard. The > suggested remedy here is to included enough of the of the information > that is reference directly in the LDP specification and then move the > reference to Informational. The minutes should capture the remarks that this is a stupid idea because (a) including one document in another to avoid a reference is a generally bad strategy for producing a coherent document set, and (b) one cannot move a document to informational when it is the only place that specifies much of the operation of the technology. > 7. T-MPLS; report from the IETF liaison to ITU-T SG15 The minutes seem to omit any mention of the entire discussion that followed Adrian's presentation. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Apr 12 13:15:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTity-0001E9-Nz; Wed, 12 Apr 2006 13:13:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTitx-0001BU-8Y for mpls@ietf.org; Wed, 12 Apr 2006 13:13:09 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTitw-0005La-Qa for mpls@ietf.org; Wed, 12 Apr 2006 13:13:09 -0400 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k3CHD1s22056; Wed, 12 Apr 2006 13:13:02 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs Date: Wed, 12 Apr 2006 13:12:58 -0400 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE08A29B06@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs Thread-Index: AcZeURSZvZnpybc3R4OuP+Bu9ptGOAAAXMWw From: "David Allan" To: , "Joel M. Halpern" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 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: , Errors-To: mpls-bounces@lists.ietf.org Hi Eric: Agree that it is not a situation that should ever arise in a persistent = fashion.... Looked at this a few years ago and concluded that with independent mode = label distribution, you could get scenarios where there were mismatches = in how specific a FEC was vs. what was in the routing LSAs, but that = would be a race condition and hooking any mismatches together would be a = bad idea....e.g. FECs had to be exact match in order to hook FTN/ILM to = NHLFE, and you needed specific routing information to install NHLFE in = the first place... So I agree that implementation wise, if there is a mismatch, then = waiting is the ideal response, the condition would go away... cheers Dave > -----Original Message----- > From: Eric W Gray [mailto:ewgray2k@netscape.net]=20 > Sent: Wednesday, April 12, 2006 12:48 PM > To: Joel M. Halpern > Cc: mpls@ietf.org > Subject: Re: [mpls] One LDP Implementation specific question=20 > of receive labelmapping for prefix FECs >=20 >=20 > If I understand the problem under discussion correctly, this is the=20 > basic scenario: >=20 > LSR-1 (Ru) -----> LSR-2 (Rd) >=20 > The initial question was related to how LSR-1 handles a label mapping=20 > received > (presumably in downstream unsolicited label advertisement=20 > mode) from LSR-2, for a FEC corresponding to an aggregate=20 > route (e.g. - 10.1.0.0/16) - if =20 > LSR-1 > does not have an exact match route entry. >=20 > Assuming that both LSRs are functioning properly and LSR-2 is=20 > using LDP=20 > to send > unsolicited label mappings for FECs that correspond to routes it has=20 > advertised, it > is unlikely that this situation will arise. LSR-1 would only receive=20 > label mappings - > from LSR-2 - for routes it (LSR-1) knows of (also from LSR-2=20 > - at least). >=20 > An implementor might decide to incorporate a delay prior to=20 > making this=20 > check, in > order to eliminate some potential race conditions. And=20 > implementors may=20 > disagree > as to what it means for LSR-1 to have an entry. But - bottom=20 > line - if=20 > the check > for an exact match between FEC and route entry finds that=20 > such an entry=20 > does not > exist in an LSR, the corresponding label must not be used. >=20 > The procedures for handling label mappings are - in part -=20 > intended to=20 > provide for > robustness in the event that another LSR is not functioning properly. >=20 > Much of the discussion surrounding this question has been=20 > about complex=20 > things > an implementation might do. None of these things are fundamentally=20 > incompatible > with the procedures as written. >=20 > -- > Eric >=20 > Joel M. Halpern wrote: >=20 > > The basic question is how much complication an implementation wishes > > to undertake to allow for the mismatch. > > Note that such mismatches are rare. > > > > As a local matter, an implementation can chose to create=20 > the FTN entry > > for the exact match, and keep track of the relationship=20 > between that=20 > > entry and the actual routing entry. Eric has argued that such is=20 > > undesirable complication. I would tend to agree with him in the=20 > > abstract. What you choose to do in your implementation may depend=20 > > upon your structures and on what problems you confront in=20 > the field. =20 > > Creating the local entries and using them is legal. Such entries=20 > > would not affect routing advertisements. They probably don't even=20 > > effect label advertisements. > > > > Yours, > > Joel M. Halpern > > > > At 04:45 PM 4/11/2006, Dutta, Pranjal wrote: > > > >> Thanks for the explanation on this. > >> > >> Let me elaborate a scenario based on the rules that you mentioned. > >> > >> For the procedure of label_map_received we have to apply both the=20 > >> rules > >> 1) and 2) right. For rule one, If Ru gets a label from Rd=20 > and Rd is NOT > >> the next hop for the FEC. How Ru decides that the FEC is=20 > not next hop > >> are > >> a) FEC exactly matches a route entry but next hop is=20 > another LSR or b) > >> As per your rule one FEC matches LPM to a shorter prefix=20 > P, and Rd is > >> not next hop for the matched prefix P. Lets say we hit=20 > issue b) and due > >> to liberal retention at Ru it retains the label but will=20 > not be used for > >> forwarding. > >> > >> Now let's say that routing at Ru changes and now Rd=20 > becomes next hop=20 > >> for Prefix P. So now Ru should introduce an entry for the FEC into=20 > >> forwarding table and install the NHLFE entry right? But=20 > that violates=20 > >> your Rule 2 then as the exact match condition should be met. If we=20 > >> apply rule 2 now, then we shouldn't use the label from Rd=20 > although Rd=20 > >> has become the next hop for Prefix P. Please correct me if=20 > I am wrong=20 > >> in this. > >> > >> Regards, > >> Pranjal > >> > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:joel@stevecrocker.com] > >> Sent: Tuesday, 11 April, 2006 7:53 PM > >> To: Dutta, Pranjal > >> Cc: mpls@ietf.org > >> Subject: Re: [mpls] One LDP Implementation specific question of=20 > >> receive label mapping for prefix FECs > >> > >> I think that there may be a better way to explain this. There are=20 > >> several different factors at work: > >> > >> 1) A received LDP label MUST NOT be used if the neighbor=20 > sending the=20 > >> label is not the next hop for the FEC. This condition does not=20 > >> require an exact match in the forwarding table. > >> 2) A Received label MUST NOT be used for packets which do=20 > not match=20 > >> the received FEC. This condition requires an exact match in the=20 > >> forwarding table. > >> > >> This does allow an implementation to create an exact match=20 > entry in=20 > >> the forwarding table to select packets that use the label, even if=20 > >> routing provided a shorter prefix. This does allow one to use /32=20 > >> entries without injecting those /32s into the actual routing=20 > >> protocol. However, the most common uses of .LDP (even with /32s)=20 > >> will result in the entries being in the forwarding table anyway. > >> > >> Another way to look at the condition above is that=20 > condition 1 is a=20 > >> restriction on the use of a received label advertisement. =20 > LPM check=20 > >> is suitable. Condition 2 is a restriction on the contents of the=20 > >> Forwarding-Table-to-Next-hop-label-forwarding-entry that=20 > one creates. =20 > >> That must be an exact match. > >> > >> Yours, > >> Joel M. Halpern > >> > >> At 07:02 AM 4/11/2006, Eric W Gray wrote: > >> >The implementation MUST do an exact match, as downstream=20 > LSRs will=20 > >> >forward based only on the label. Because they do not (typically)=20 > >> >perform a route look-up on the label > >> >encapsulated inner IP packet, there is no reason to expect a > >> >downstream LSR to be able > >> >to separate a flow based on longest match when the routes further > >> >downstream are distinct > >> >for "longer matches". > >> > > >> >Dutta, Pranjal wrote: > >> > > >> >> > >> >>Hi Eric, > >> >> As per RFC 3036 Label mapping receive=20 > procedures, when=20 > >> >>Ru received a label mapping from Rd for a FEC x, Ru need=20 > to find an > >> "exact" > >> >>match of the FEC x(IPv4/V6 prefix) in its route table. In > >> Inter-IGP-area > >> >>or inter-AS case the routes from Rd would be summarized=20 > to Ru and=20 > >> >>in such a case Ru MAY not find the exact match for such=20 > FEC x. In=20 > >> >>terms > >> of > >> >>RFC 3036 then Ru MAY not find exact match for the FEC=20 > received from=20 > >> >>Rd in its route table and no further action at Ru. My=20 > question was=20 > >> >>why Ru can't we do a longest prefix match for the FEC x as LPM=20 > >> >>means it can > >> be > >> >>reached by a downstream Rd? > >> >> > >> >>Thanks, > >> >>Pranjal > >> > > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls > > > > > > >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Apr 12 13:20:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTizA-0004bX-1F; Wed, 12 Apr 2006 13:18:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTiz8-0004bS-Nq for mpls@ietf.org; Wed, 12 Apr 2006 13:18:30 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTiz8-0005Zl-6n for mpls@ietf.org; Wed, 12 Apr 2006 13:18:30 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Apr 2006 19:18:15 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs Date: Wed, 12 Apr 2006 19:18:14 +0200 Message-ID: <5A0FF108221C7C4E85738678804B567C032CD525@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs Thread-Index: AcZeUQ25hojuFEeoTdWW6BXaZ310jwAARh4Q From: "DECRAENE Bruno RD-CORE-ISS" To: X-OriginalArrivalTime: 12 Apr 2006 17:18:15.0939 (UTC) FILETIME=[15E7ED30:01C65E55] X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 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: , Errors-To: mpls-bounces@lists.ietf.org Eric, > From: Eric W Gray [mailto:ewgray2k@netscape.net] > If I understand the problem under discussion correctly, this is the > basic scenario: >=20 > LSR-1 (Ru) -----> LSR-2 (Rd) >=20 > The initial question was related to how LSR-1 handles a label mapping > received > (presumably in downstream unsolicited label advertisement mode) from LSR-2, > for a FEC corresponding to an aggregate route (e.g. - 10.1.0.0/16) - if > LSR-1 > does not have an exact match route entry. >=20 > Assuming that both LSRs are functioning properly and LSR-2 is using LDP > to send > unsolicited label mappings for FECs that correspond to routes it has > advertised, it > is unlikely that this situation will arise. [Bruno D:] That is correct if Ru and Rd are in the same IGP area. Otherwise, if IP aggregation is performed between areas, Ru and Rd may not have the same IP route knowledge. In particular, if Rd is an Area Border Router, it may aggregate IP reachability information send to Ru. Therefore, Rd will not advertise the specific IP route to Ru. You may also have a look at section 4.1 of draft-decraene-mpls-ldp-interarea-01.txt for more details on this use case. > LSR-1 would only receive > label mappings - > from LSR-2 - for routes it (LSR-1) knows of (also from LSR-2 - at least). >=20 > An implementor might decide to incorporate a delay prior to making this > check, in > order to eliminate some potential race conditions. And implementors may > disagree > as to what it means for LSR-1 to have an entry. But - bottom line - if > the check > for an exact match between FEC and route entry finds that such an entry > does not > exist in an LSR, the corresponding label must not be used. >=20 > The procedures for handling label mappings are - in part - intended to > provide for > robustness in the event that another LSR is not functioning properly. >=20 > Much of the discussion surrounding this question has been about complex > things > an implementation might do. None of these things are fundamentally > incompatible > with the procedures as written. >=20 > -- > Eric >=20 > Joel M. Halpern wrote: >=20 > > The basic question is how much complication an implementation wishes > > to undertake to allow for the mismatch. > > Note that such mismatches are rare. > > > > As a local matter, an implementation can chose to create the FTN entry > > for the exact match, and keep track of the relationship between that > > entry and the actual routing entry. Eric has argued that such is > > undesirable complication. I would tend to agree with him in the > > abstract. What you choose to do in your implementation may depend > > upon your structures and on what problems you confront in the field. > > Creating the local entries and using them is legal. Such entries > > would not affect routing advertisements. They probably don't even > > effect label advertisements. > > > > Yours, > > Joel M. Halpern > > > > At 04:45 PM 4/11/2006, Dutta, Pranjal wrote: > > > >> Thanks for the explanation on this. > >> > >> Let me elaborate a scenario based on the rules that you mentioned. > >> > >> For the procedure of label_map_received we have to apply both the rules > >> 1) and 2) right. For rule one, If Ru gets a label from Rd and Rd is NOT > >> the next hop for the FEC. How Ru decides that the FEC is not next hop > >> are > >> a) FEC exactly matches a route entry but next hop is another LSR or b) > >> As per your rule one FEC matches LPM to a shorter prefix P, and Rd is > >> not next hop for the matched prefix P. Lets say we hit issue b) and due > >> to liberal retention at Ru it retains the label but will not be used for > >> forwarding. > >> > >> Now let's say that routing at Ru changes and now Rd becomes next hop for > >> Prefix P. So now Ru should introduce an entry for the FEC into > >> forwarding table and install the NHLFE entry right? But that violates > >> your Rule 2 then > >> as the exact match condition should be met. If we apply rule 2 now, then > >> we shouldn't use the label from Rd although Rd has become the next hop > >> for Prefix P. Please correct me if I am wrong in this. > >> > >> Regards, > >> Pranjal > >> > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:joel@stevecrocker.com] > >> Sent: Tuesday, 11 April, 2006 7:53 PM > >> To: Dutta, Pranjal > >> Cc: mpls@ietf.org > >> Subject: Re: [mpls] One LDP Implementation specific question of receive > >> label mapping for prefix FECs > >> > >> I think that there may be a better way to explain this. There are > >> several different factors at work: > >> > >> 1) A received LDP label MUST NOT be used if the neighbor sending the > >> label is not the next hop for the FEC. This condition does not > >> require an exact match in the forwarding table. > >> 2) A Received label MUST NOT be used for packets which do not match > >> the received FEC. This condition requires an exact match in the > >> forwarding table. > >> > >> This does allow an implementation to create an exact match entry in > >> the forwarding table to select packets that use the label, even if > >> routing provided a shorter prefix. This does allow one to use /32 > >> entries without injecting those /32s into the actual routing > >> protocol. However, the most common uses of .LDP (even with /32s) > >> will result in the entries being in the forwarding table anyway. > >> > >> Another way to look at the condition above is that condition 1 is a > >> restriction on the use of a received label advertisement. LPM check > >> is suitable. Condition 2 is a restriction on the contents of the > >> Forwarding-Table-to-Next-hop-label-forwarding-entry that one > >> creates. That must be an exact match. > >> > >> Yours, > >> Joel M. Halpern > >> > >> At 07:02 AM 4/11/2006, Eric W Gray wrote: > >> >The implementation MUST do an exact match, as downstream LSRs will > >> >forward based > >> >only on the label. Because they do not (typically) perform a route > >> >look-up on the label > >> >encapsulated inner IP packet, there is no reason to expect a > >> >downstream LSR to be able > >> >to separate a flow based on longest match when the routes further > >> >downstream are distinct > >> >for "longer matches". > >> > > >> >Dutta, Pranjal wrote: > >> > > >> >> > >> >>Hi Eric, > >> >> As per RFC 3036 Label mapping receive procedures, when Ru > >> >>received a label mapping from Rd for a FEC x, Ru need to find an > >> "exact" > >> >>match of the FEC x(IPv4/V6 prefix) in its route table. In > >> Inter-IGP-area > >> >>or inter-AS case the routes from Rd would be summarized to Ru and in > >> >>such a case Ru MAY not find the exact match for such FEC x. In terms > >> of > >> >>RFC 3036 then Ru MAY not find exact match for the FEC received from Rd > >> >>in its route table and no further action at Ru. My question was why Ru > >> >>can't we do a longest prefix match for the FEC x as LPM means it can > >> be > >> >>reached by a downstream Rd? > >> >> > >> >>Thanks, > >> >>Pranjal > >> > > > > > > > > > _______________________________________________ > > 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 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Apr 12 15:53:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTlMS-00072J-U2; Wed, 12 Apr 2006 15:50:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTlLp-0005dh-1h; Wed, 12 Apr 2006 15:50:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTlLo-0002DW-Vk; Wed, 12 Apr 2006 15:50:05 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FTlLm-0005hx-Hz; Wed, 12 Apr 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k3CJo20e019111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Apr 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FTlLm-0002gQ-4f; Wed, 12 Apr 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 12 Apr 2006 15:50:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: mpls@lists.ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-lsp-ping-01.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: , Errors-To: mpls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Detecting Data Plane Failures in Point-to-Multipoint MPLS Traffic Engineering - Extensions to LSP Ping Author(s) : S. Yasukawa, et al. Filename : draft-ietf-mpls-p2mp-lsp-ping-01.txt Pages : 18 Date : 2006-4-12 Recent proposals have extended the scope of Multi-Protocol Label Switching (MPLS) traffic engineered Label Switched Paths (TE LSPs) to encompass point-to-multipoint (P2MP) TE LSPs. The requirement for a simple and efficient mechanism that can be used to detect data plane failures in point-to-point (P2P) MPLS LSPs has been recognised and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP Ping". The scope of this document is fault detection and isolation for P2MP MPLS TE LSPs. This documents does not replace any of the mechanism of LSP Ping, but clarifies their applicability to P2MP MPLS TE LSPs, and extends the techniques and mechanisms of LSP Ping to the P2MP TE environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-lsp-ping-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-p2mp-lsp-ping-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-p2mp-lsp-ping-01.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: <2006-4-12112809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-p2mp-lsp-ping-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-p2mp-lsp-ping-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-12112809.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Wed Apr 12 16:20:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTlnE-0000OG-Bn; Wed, 12 Apr 2006 16:18:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTlRu-0000IH-LJ for mpls@ietf.org; Wed, 12 Apr 2006 15:56:22 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTlRs-0003w9-BT for mpls@ietf.org; Wed, 12 Apr 2006 15:56:21 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1FTlRn-0004U6-00 for mpls@ietf.org; Wed, 12 Apr 2006 20:56:15 +0100 Received: from Puppy ([217.158.132.12] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Apr 2006 20:56:52 +0100 Message-ID: <111001c65e6b$3501a650$bf849ed9@Puppy> From: "Adrian Farrel" To: , "Loa Andersson" References: <200604121702.k3CH2fTL010801@rtp-core-1.cisco.com> Subject: Re: [mpls] draft working group minutes from Dallas Date: Wed, 12 Apr 2006 20:56:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 12 Apr 2006 19:56:53.0078 (UTC) FILETIME=[3E901760:01C65E6B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org > > 7. T-MPLS; report from the IETF liaison to ITU-T SG15 > > The minutes seem to omit any mention of the entire discussion that followed > Adrian's presentation. Not to mention the fact that I got shot anyway :-( _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Apr 13 01:18:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTuAd-000271-I8; Thu, 13 Apr 2006 01:15:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTuAb-000261-Bd for mpls@ietf.org; Thu, 13 Apr 2006 01:15:05 -0400 Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTuAW-0006Hv-Pp for mpls@ietf.org; Thu, 13 Apr 2006 01:15:05 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id WAA01229; Wed, 12 Apr 2006 22:14:54 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs Date: Thu, 13 Apr 2006 10:44:53 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs Thread-Index: AcZeUQcdm7cHDjakRwaJB0UBkhymjgAZbT5w From: "Dutta, Pranjal" To: , "Joel M. Halpern" X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 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: , Errors-To: mpls-bounces@lists.ietf.org Hi, Please follow inline. Thanks, Pranjal -----Original Message----- From: Eric W Gray [mailto:ewgray2k@netscape.net]=20 Sent: Wednesday, 12 April, 2006 10:18 PM To: Joel M. Halpern Cc: Dutta, Pranjal; mpls@ietf.org Subject: Re: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs If I understand the problem under discussion correctly, this is the=20 basic scenario: LSR-1 (Ru) -----> LSR-2 (Rd) The initial question was related to how LSR-1 handles a label mapping=20 received (presumably in downstream unsolicited label advertisement mode) from LSR-2, for a FEC corresponding to an aggregate route (e.g. - 10.1.0.0/16) - if LSR-1 does not have an exact match route entry. Assuming that both LSRs are functioning properly and LSR-2 is using LDP=20 to send unsolicited label mappings for FECs that correspond to routes it has=20 advertised, it is unlikely that this situation will arise. LSR-1 would only receive=20 label mappings - from LSR-2 - for routes it (LSR-1) knows of (also from LSR-2 - at least). [Pranjal]: The issue I raised is the situation when Rd summarizes the routes to Ru. So Rd has more specific routes and Ru has summarized route. This would be the case when Ru and Rd are in different IGP Areas or AS domains. In that case, in downstream unsolicited Rd will advertise a label mapping for those more specific prefixes (FECs). Ru won't find exact match, but may find a longest prefix match. Now as per RFC 3036 and as you said we should do exact match for the FEC =20 An implementor might decide to incorporate a delay prior to making this=20 check, in order to eliminate some potential race conditions. And implementors may disagree as to what it means for LSR-1 to have an entry. But - bottom line - if=20 the check for an exact match between FEC and route entry finds that such an entry=20 does not exist in an LSR, the corresponding label must not be used. The procedures for handling label mappings are - in part - intended to=20 provide for robustness in the event that another LSR is not functioning properly. Much of the discussion surrounding this question has been about complex=20 things an implementation might do. None of these things are fundamentally=20 incompatible with the procedures as written. [Pranjal]: Yes, there are certain things like introducing delay to handle race condition as you said are implementer's choice. But I have to follow the basic tenet now, that is the *exact* match for FEC binding.=20 -- Eric Joel M. Halpern wrote: > The basic question is how much complication an implementation wishes=20 > to undertake to allow for the mismatch. > Note that such mismatches are rare. > > As a local matter, an implementation can chose to create the FTN entry > for the exact match, and keep track of the relationship between that=20 > entry and the actual routing entry. Eric has argued that such is=20 > undesirable complication. I would tend to agree with him in the=20 > abstract. What you choose to do in your implementation may depend=20 > upon your structures and on what problems you confront in the field. =20 > Creating the local entries and using them is legal. Such entries=20 > would not affect routing advertisements. They probably don't even=20 > effect label advertisements. > > Yours, > Joel M. Halpern > > At 04:45 PM 4/11/2006, Dutta, Pranjal wrote: > >> Thanks for the explanation on this. >> >> Let me elaborate a scenario based on the rules that you mentioned. >> >> For the procedure of label_map_received we have to apply both the rules >> 1) and 2) right. For rule one, If Ru gets a label from Rd and Rd is NOT >> the next hop for the FEC. How Ru decides that the FEC is not next hop >> are >> a) FEC exactly matches a route entry but next hop is another LSR or b) >> As per your rule one FEC matches LPM to a shorter prefix P, and Rd is >> not next hop for the matched prefix P. Lets say we hit issue b) and due >> to liberal retention at Ru it retains the label but will not be used for >> forwarding. >> >> Now let's say that routing at Ru changes and now Rd becomes next hop for >> Prefix P. So now Ru should introduce an entry for the FEC into >> forwarding table and install the NHLFE entry right? But that violates >> your Rule 2 then >> as the exact match condition should be met. If we apply rule 2 now, then >> we shouldn't use the label from Rd although Rd has become the next hop >> for Prefix P. Please correct me if I am wrong in this. >> >> Regards, >> Pranjal >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:joel@stevecrocker.com] >> Sent: Tuesday, 11 April, 2006 7:53 PM >> To: Dutta, Pranjal >> Cc: mpls@ietf.org >> Subject: Re: [mpls] One LDP Implementation specific question of receive >> label mapping for prefix FECs >> >> I think that there may be a better way to explain this. There are >> several different factors at work: >> >> 1) A received LDP label MUST NOT be used if the neighbor sending the >> label is not the next hop for the FEC. This condition does not >> require an exact match in the forwarding table. >> 2) A Received label MUST NOT be used for packets which do not match >> the received FEC. This condition requires an exact match in the >> forwarding table. >> >> This does allow an implementation to create an exact match entry in >> the forwarding table to select packets that use the label, even if >> routing provided a shorter prefix. This does allow one to use /32 >> entries without injecting those /32s into the actual routing >> protocol. However, the most common uses of .LDP (even with /32s) >> will result in the entries being in the forwarding table anyway. >> >> Another way to look at the condition above is that condition 1 is a >> restriction on the use of a received label advertisement. LPM check >> is suitable. Condition 2 is a restriction on the contents of the >> Forwarding-Table-to-Next-hop-label-forwarding-entry that one >> creates. That must be an exact match. >> >> Yours, >> Joel M. Halpern >> >> At 07:02 AM 4/11/2006, Eric W Gray wrote: >> >The implementation MUST do an exact match, as downstream LSRs will >> >forward based >> >only on the label. Because they do not (typically) perform a route >> >look-up on the label >> >encapsulated inner IP packet, there is no reason to expect a >> >downstream LSR to be able >> >to separate a flow based on longest match when the routes further >> >downstream are distinct >> >for "longer matches". >> > >> >Dutta, Pranjal wrote: >> > >> >> >> >>Hi Eric, >> >> As per RFC 3036 Label mapping receive procedures, when Ru >> >>received a label mapping from Rd for a FEC x, Ru need to find an >> "exact" >> >>match of the FEC x(IPv4/V6 prefix) in its route table. In >> Inter-IGP-area >> >>or inter-AS case the routes from Rd would be summarized to Ru and in >> >>such a case Ru MAY not find the exact match for such FEC x. In terms >> of >> >>RFC 3036 then Ru MAY not find exact match for the FEC received from Rd >> >>in its route table and no further action at Ru. My question was why Ru >> >>can't we do a longest prefix match for the FEC x as LPM means it can >> be >> >>reached by a downstream Rd? >> >> >> >>Thanks, >> >>Pranjal >> > > > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Apr 13 04:51:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTxWT-00061o-Hk; Thu, 13 Apr 2006 04:49:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTxWR-00061j-LT for mpls@ietf.org; Thu, 13 Apr 2006 04:49:51 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTxWR-0004Ac-6x for mpls@ietf.org; Thu, 13 Apr 2006 04:49:51 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 10:27:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs Date: Thu, 13 Apr 2006 10:27:48 +0200 Message-ID: <5A0FF108221C7C4E85738678804B567C032CD625@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs Thread-Index: AcZdkGF0HAfdYjkYTQeT18n4v40zdQAo6P4w From: "DECRAENE Bruno RD-CORE-ISS" To: X-OriginalArrivalTime: 13 Apr 2006 08:27:48.0742 (UTC) FILETIME=[25D4D260:01C65ED4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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: , Errors-To: mpls-bounces@lists.ietf.org Eric, Thanks for your comments. Additional discussions inlined. Regards, Bruno > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Tuesday, April 11, 2006 7:50 PM > To: Dutta, Pranjal > Cc: mpls@ietf.org > Subject: Re: [mpls] One LDP Implementation specific question of receive labelmapping for prefix > FECs >=20 >=20 > > In Inter-IGP-area or inter-AS case the routes from Rd would be summarized > > to Ru and in such a case Ru MAY not find the exact match for such FEC x >=20 > If I understand your example, Ru has the summary route, Rd has the more > specific routes, and Rd is sending Ru label bindings for the more specific > routes but not for the summary route. You don't say anything about Ru > itself distributing labels bindings for the more specific routes, so > presumably the only thing at issue is Ru should label an IP packet that it > receives. =20 [Bruno D:] A subsequent issue, is that to continue the LSP further upstream, Ru should allocate a new label and advertise the specific FEC upstream to Ruu. > What will happen is that the IP packet gets sent unlabeled to Rd > which then labels it according to the specific route which is the best match > to the packet's IP destination address. [Bruno D:] That is indeed the current behavior but the problem is that Rd may not be able to forward the IP packet (eg Ru is a VPN PE and Rd is a P). And this may not be an IP packet BTW. =20 > The label imposition procedure here is: >=20 > - get the IP destination address > - find the prefix in the routing table which is the best match (longest > match) for that destination address > - use the label which was assigned to that prefix by the LSR which routing > says is the next hop for that prefix. >=20 > It doesn't make sense for Rd to bind labels to prefixes which are more > specific than the one in the routing table, as the label imposition > procedure will never make use of such labels. >=20 > I don't think we want to allow LDP to put prefixes in the routing table, or > else we'd have to treat it as a second routing algorithm and that would > raise all kinds of issues. [Bruno D:] Such procedure would not change the behavior of the IGP and LDP. LDP would definitely not act as a routing protocol and all routing decisions (next-hop selection, recheability) would still rely on the IGP. LDP would continue advertising labels for FECs and would entirely rely on the RIB for setting up LSPs along the IP route. However, as you very correctly pointed out, we would allow LDP to "de-aggregate" the FIB and this may raise some issue. However, what is the difference, from the FIB point of view, between one /30 pointing to Rd and four /32 pointing to Rd? I believe some FIB implementation already represent a /30 as four /32. Besides, if populating the FTN with specific FEC is found to be an issue, we can only populate the ILM on all P routers. For PE/ingress router, all we really need is BGP to be aware of these LSPs and be able to use them to reach the BGP Next Hops. > It is possible though to imagine a different imposition procedure: >=20 > - get the IP destination address, A >=20 > - find the prefix, P, in the routing table which is the best match (longest > match) for that destination address >=20 > - get the next hop, N, for P, as specified by routing >=20 > - if N has distributed any label bindings for prefixes which are longer than > P but begin with the same sequence of bits as P, and if any of these, say > Q, is a better match for A than P, then use the label which N assigned to > Q. >=20 > This is a complicated procedure, though. You can't just match A against Q, > because there might be some prefix R in the routing table, with a different > next hop, which is a better match for A than P is, but not as good a match > as Q. The above imposition procedure says that the next hop for the packet > is determined by the route to R not by the route to P (or Q). It's a > complex matter to keep the forwarding tables in proper shape, given that > prefixes like Q can come and go asynchronously. [Bruno D:] I don't think there is a need to change the imposition procedure at all. The modification of the label mapping procedure seems enough. However, as pointing out by Dutta, an additional effort is needed to sync LDP with the RIB because as you said, more specific prefixes can come and go. =20 > There are other complications as well. For example, what do you do if you > get a packet which is labeled for Q, but the next hop has changed and the > new next hop has not distributed a label for Q? >=20 > I suppose we could figure all this out if there were an actual problem which > didn't have a better solution. >=20 >=20 >=20 >=20 >=20 >=20 >=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 From mpls-bounces@lists.ietf.org Thu Apr 13 06:46:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTzJL-00033L-RM; Thu, 13 Apr 2006 06:44:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTzJJ-00033G-Np for mpls@lists.ietf.org; Thu, 13 Apr 2006 06:44:25 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTzJI-0007x4-Bh for mpls@lists.ietf.org; Thu, 13 Apr 2006 06:44:25 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Apr 2006 11:44:23 +0100 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Apr 2006 11:44:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-lsp-ping-01.txt Date: Thu, 13 Apr 2006 11:44:21 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-lsp-ping-01.txt Thread-Index: AcZeandujIY3UM6LSmuXKVMLE1tAcgAe42Og From: To: X-OriginalArrivalTime: 13 Apr 2006 10:44:23.0082 (UTC) FILETIME=[3A09E0A0:01C65EE7] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: , Errors-To: mpls-bounces@lists.ietf.org Colleagues, I have a couple of comments on this draft. 1) Why is it restricted to P2MP TE LSPs? mLDP signalled LSPs will also require OAM and it's not clear to me why they have been precluded by this draft. 2) Section 4.1 of draft-ietf-mpls-p2mp-oam-reqs-01 states "The ability to detect defects in a P2MP LSP SHOULD not require manual, hop-by-hop troubleshooting of each LSR used to switch traffic for that LSP, and SHOULD rely on proactive OAM procedures (such as continuous path connectivity and SLA measurement mechanisms)." whereas the comments in draft-ietf-mpls-p2mp-lsp-ping-01 imply to me that proactive/continuous OAM may not be possible with the proposed solution due to scaling concerns resulting from the possibility of flooding the ingress with responses. As well as the ability to delay/jitter the echo responses has consideration been given to other potential ways to improve scalabilty for example using a Nack model for responses, somehow aggregating responses etc.? Thanks Ben --=20 Ben Niven-Jenkins Network Architect, BT Exact =20 E-mail: benjamin.niven-jenkins@bt.com=20 Office: +44 (0)1473 648225 Mobile: +44 (0)7918 077205 Fax: +44 (0)1332 578827 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Apr 13 07:27:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTzx0-0003iO-ML; Thu, 13 Apr 2006 07:25:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTzwy-0003Yn-SB for mpls@lists.ietf.org; Thu, 13 Apr 2006 07:25:24 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTzwv-0000fD-DP for mpls@lists.ietf.org; Thu, 13 Apr 2006 07:25:24 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1FTzwr-0004Gn-00 for mpls@lists.ietf.org; Thu, 13 Apr 2006 12:25:17 +0100 Received: from Puppy ([217.158.132.166] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 12:25:51 +0100 Message-ID: <11b901c65eec$fc8bc8f0$bf849ed9@Puppy> From: "Adrian Farrel" To: References: Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-lsp-ping-01.txt Date: Thu, 13 Apr 2006 12:13:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 13 Apr 2006 11:25:51.0906 (UTC) FILETIME=[057E4820:01C65EED] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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: , Errors-To: mpls-bounces@lists.ietf.org FYI, This is mainly a re-spin to keep the draft alive. I took the opportunity to update the references as well. Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Apr 13 08:09:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU0bw-0000MM-9i; Thu, 13 Apr 2006 08:07:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU0bv-0000MH-Ag for mpls@ietf.org; Thu, 13 Apr 2006 08:07:43 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU0bv-0001sF-3o for mpls@ietf.org; Thu, 13 Apr 2006 08:07:43 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 13 Apr 2006 08:07:43 -0400 X-IronPort-AV: i="4.04,117,1144036800"; d="scan'208"; a="86360489:sNHT29778672" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3DC7jTL019055; Thu, 13 Apr 2006 08:07:45 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Apr 2006 08:07:42 -0400 Received: from [10.83.15.57] ([10.83.15.57]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Apr 2006 08:07:42 -0400 In-Reply-To: <111001c65e6b$3501a650$bf849ed9@Puppy> References: <200604121702.k3CH2fTL010801@rtp-core-1.cisco.com> <111001c65e6b$3501a650$bf849ed9@Puppy> Mime-Version: 1.0 (Apple Message framework v749.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [mpls] draft working group minutes from Dallas Date: Thu, 13 Apr 2006 08:07:48 -0400 To: Adrian Farrel X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 13 Apr 2006 12:07:42.0251 (UTC) FILETIME=[DDC687B0:01C65EF2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org On Apr 12, 2006, at 3:56 PM, Adrian Farrel wrote: > >>> 7. T-MPLS; report from the IETF liaison to ITU-T SG15 >> >> The minutes seem to omit any mention of the entire discussion that > followed >> Adrian's presentation. > > Not to mention the fact that I got shot anyway :-( I think my version of the meeting minutes had you being sent to the hospital with *multiple* shot wounds. *) --Tom > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Apr 13 09:46:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU277-0001PE-KT; Thu, 13 Apr 2006 09:44:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU276-0001P9-HO for mpls@ietf.org; Thu, 13 Apr 2006 09:44:00 -0400 Received: from imo-d01.mx.aol.com ([205.188.157.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU272-0005Eg-RX for mpls@ietf.org; Thu, 13 Apr 2006 09:43:58 -0400 Received: from ewgray2k@netscape.net by imo-d01.mx.aol.com (mail_out_v38_r7.3.) id h.1b4.11fc3c9a (22680); Thu, 13 Apr 2006 09:43:36 -0400 (EDT) Received: from [192.168.3.101] (c-24-128-207-21.hsd1.nh.comcast.net [24.128.207.21]) by air-in04.mx.aol.com (v108_r3.6) with ESMTP id MAILININ41-5898443e5587217; Thu, 13 Apr 2006 09:43:35 -0400 Message-ID: <443E555B.7020800@netscape.net> Date: Thu, 13 Apr 2006 09:42:51 -0400 From: Eric W Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Dutta, Pranjal" Subject: Re: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs References: In-Reply-To: X-AOL-IP: 24.128.207.21 X-Mailer: Unknown (No Version) X-Spam-Flag: NO X-Spam-Score: 0.1 (/) X-Scan-Signature: a83e8b750067501be8b56bf02fb6582d Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@GraIyMage.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0824086677==" Errors-To: mpls-bounces@lists.ietf.org --===============0824086677== Content-Type: multipart/alternative; boundary="------------050305020900080005040502" --------------050305020900080005040502 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pranjal, Actually, Rd should not distribute labels for more specific routes than it has advertised. This is exactly what is broken in the scenario you describe. What exactly is the point in distributing these labels, if the routing paradigm uses summarization to achieve scalability? As someone (I think Yakov Rekhter) said many years ago, MPLS is scalable precisely because routing is scalable. -- Eric Dutta, Pranjal wrote: >Hi, > Please follow inline. > >Thanks, >Pranjal > >-----Original Message----- >From: Eric W Gray [mailto:ewgray2k@netscape.net] >Sent: Wednesday, 12 April, 2006 10:18 PM >To: Joel M. Halpern >Cc: Dutta, Pranjal; mpls@ietf.org >Subject: Re: [mpls] One LDP Implementation specific question of receive >label mapping for prefix FECs > >If I understand the problem under discussion correctly, this is the >basic scenario: > > LSR-1 (Ru) -----> LSR-2 (Rd) > >The initial question was related to how LSR-1 handles a label mapping >received >(presumably in downstream unsolicited label advertisement mode) from >LSR-2, >for a FEC corresponding to an aggregate route (e.g. - 10.1.0.0/16) - if > >LSR-1 >does not have an exact match route entry. > >Assuming that both LSRs are functioning properly and LSR-2 is using LDP >to send >unsolicited label mappings for FECs that correspond to routes it has >advertised, it >is unlikely that this situation will arise. LSR-1 would only receive >label mappings - >from LSR-2 - for routes it (LSR-1) knows of (also from LSR-2 - at >least). > >[Pranjal]: The issue I raised is the situation when Rd summarizes the >routes to Ru. So Rd has more specific routes and Ru has summarized >route. This would be the case when Ru and Rd are in different IGP Areas >or AS domains. >In that case, in downstream unsolicited Rd will advertise a label >mapping for those more specific prefixes (FECs). Ru won't find exact >match, but may find a longest prefix match. Now as per RFC 3036 and as >you said we should do exact match for the FEC > >An implementor might decide to incorporate a delay prior to making this >check, in >order to eliminate some potential race conditions. And implementors may > >disagree >as to what it means for LSR-1 to have an entry. But - bottom line - if >the check >for an exact match between FEC and route entry finds that such an entry >does not >exist in an LSR, the corresponding label must not be used. > >The procedures for handling label mappings are - in part - intended to >provide for >robustness in the event that another LSR is not functioning properly. > >Much of the discussion surrounding this question has been about complex >things >an implementation might do. None of these things are fundamentally >incompatible >with the procedures as written. > >[Pranjal]: Yes, there are certain things like introducing delay to >handle race condition as you said are implementer's choice. But I have >to follow the basic tenet now, that is the *exact* match for FEC >binding. >-- >Eric > >Joel M. Halpern wrote: > > > >>The basic question is how much complication an implementation wishes >>to undertake to allow for the mismatch. >>Note that such mismatches are rare. >> >>As a local matter, an implementation can chose to create the FTN entry >> >> > > > >>for the exact match, and keep track of the relationship between that >>entry and the actual routing entry. Eric has argued that such is >>undesirable complication. I would tend to agree with him in the >>abstract. What you choose to do in your implementation may depend >>upon your structures and on what problems you confront in the field. >>Creating the local entries and using them is legal. Such entries >>would not affect routing advertisements. They probably don't even >>effect label advertisements. >> >>Yours, >>Joel M. Halpern >> >>At 04:45 PM 4/11/2006, Dutta, Pranjal wrote: >> >> >> >>>Thanks for the explanation on this. >>> >>>Let me elaborate a scenario based on the rules that you mentioned. >>> >>>For the procedure of label_map_received we have to apply both the >>> >>> >rules > > >>>1) and 2) right. For rule one, If Ru gets a label from Rd and Rd is >>> >>> >NOT > > >>>the next hop for the FEC. How Ru decides that the FEC is not next hop >>>are >>>a) FEC exactly matches a route entry but next hop is another LSR or >>> >>> >b) > > >>>As per your rule one FEC matches LPM to a shorter prefix P, and Rd is >>>not next hop for the matched prefix P. Lets say we hit issue b) and >>> >>> >due > > >>>to liberal retention at Ru it retains the label but will not be used >>> >>> >for > > >>>forwarding. >>> >>>Now let's say that routing at Ru changes and now Rd becomes next hop >>> >>> >for > > >>>Prefix P. So now Ru should introduce an entry for the FEC into >>>forwarding table and install the NHLFE entry right? But that violates >>>your Rule 2 then >>>as the exact match condition should be met. If we apply rule 2 now, >>> >>> >then > > >>>we shouldn't use the label from Rd although Rd has become the next >>> >>> >hop > > >>>for Prefix P. Please correct me if I am wrong in this. >>> >>>Regards, >>>Pranjal >>> >>>-----Original Message----- >>>From: Joel M. Halpern [mailto:joel@stevecrocker.com] >>>Sent: Tuesday, 11 April, 2006 7:53 PM >>>To: Dutta, Pranjal >>>Cc: mpls@ietf.org >>>Subject: Re: [mpls] One LDP Implementation specific question of >>> >>> >receive > > >>>label mapping for prefix FECs >>> >>>I think that there may be a better way to explain this. There are >>>several different factors at work: >>> >>>1) A received LDP label MUST NOT be used if the neighbor sending the >>>label is not the next hop for the FEC. This condition does not >>>require an exact match in the forwarding table. >>>2) A Received label MUST NOT be used for packets which do not match >>>the received FEC. This condition requires an exact match in the >>>forwarding table. >>> >>>This does allow an implementation to create an exact match entry in >>>the forwarding table to select packets that use the label, even if >>>routing provided a shorter prefix. This does allow one to use /32 >>>entries without injecting those /32s into the actual routing >>>protocol. However, the most common uses of .LDP (even with /32s) >>>will result in the entries being in the forwarding table anyway. >>> >>>Another way to look at the condition above is that condition 1 is a >>>restriction on the use of a received label advertisement. LPM check >>>is suitable. Condition 2 is a restriction on the contents of the >>>Forwarding-Table-to-Next-hop-label-forwarding-entry that one >>>creates. That must be an exact match. >>> >>>Yours, >>>Joel M. Halpern >>> >>>At 07:02 AM 4/11/2006, Eric W Gray wrote: >>> >>> >>>>The implementation MUST do an exact match, as downstream LSRs will >>>>forward based >>>>only on the label. Because they do not (typically) perform a route >>>>look-up on the label >>>>encapsulated inner IP packet, there is no reason to expect a >>>>downstream LSR to be able >>>>to separate a flow based on longest match when the routes further >>>>downstream are distinct >>>>for "longer matches". >>>> >>>>Dutta, Pranjal wrote: >>>> >>>> >>>> >>>>>Hi Eric, >>>>> As per RFC 3036 Label mapping receive procedures, when >>>>> >>>>> >Ru > > >>>>>received a label mapping from Rd for a FEC x, Ru need to find an >>>>> >>>>> >>>"exact" >>> >>> >>>>>match of the FEC x(IPv4/V6 prefix) in its route table. In >>>>> >>>>> >>>Inter-IGP-area >>> >>> >>>>>or inter-AS case the routes from Rd would be summarized to Ru and >>>>> >>>>> >in > > >>>>>such a case Ru MAY not find the exact match for such FEC x. In >>>>> >>>>> >terms > > >>>of >>> >>> >>>>>RFC 3036 then Ru MAY not find exact match for the FEC received from >>>>> >>>>> >Rd > > >>>>>in its route table and no further action at Ru. My question was why >>>>> >>>>> >Ru > > >>>>>can't we do a longest prefix match for the FEC x as LPM means it >>>>> >>>>> >can > > >>>be >>> >>> >>>>>reached by a downstream Rd? >>>>> >>>>>Thanks, >>>>>Pranjal >>>>> >>>>> >> >>_______________________________________________ >>mpls mailing list >>mpls@lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/mpls >> >> >> >> >> > > > > > --------------050305020900080005040502 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Pranjal,

    Actually, Rd should not distribute labels for more specific routes than it has advertised.

    This is exactly what is broken in the scenario you describe.  What exactly is the point in
distributing these labels, if the routing paradigm uses summarization to achieve scalability?

    As someone (I think Yakov Rekhter) said many years ago, MPLS is scalable precisely
because routing is scalable.

--
Eric

Dutta, Pranjal wrote:
Hi,
       Please follow inline.

Thanks,
Pranjal

-----Original Message-----
From: Eric W Gray [mailto:ewgray2k@netscape.net] 
Sent: Wednesday, 12 April, 2006 10:18 PM
To: Joel M. Halpern
Cc: Dutta, Pranjal; mpls@ietf.org
Subject: Re: [mpls] One LDP Implementation specific question of receive
label mapping for prefix FECs

If I understand the problem under discussion correctly, this is the 
basic scenario:

         LSR-1 (Ru) -----> LSR-2 (Rd)

The initial question was related to how LSR-1 handles a label mapping 
received
(presumably in downstream unsolicited label advertisement mode) from
LSR-2,
for a FEC corresponding to an aggregate route (e.g. - 10.1.0.0/16) - if

LSR-1
does not have an exact match route entry.

Assuming that both LSRs are functioning properly and LSR-2 is using LDP 
to send
unsolicited label mappings for FECs that correspond to routes it has 
advertised, it
is unlikely that this situation will arise.  LSR-1 would only receive 
label mappings -
from LSR-2 - for routes it (LSR-1) knows of (also from LSR-2 - at
least).

[Pranjal]: The issue I raised is the situation when Rd summarizes the
routes to Ru. So Rd has more specific routes and Ru has summarized
route. This would be the case when Ru and Rd are in different IGP Areas
or AS domains.
In that case, in downstream unsolicited Rd will advertise a label
mapping for those more specific prefixes (FECs). Ru won't find exact
match, but may find a longest prefix match. Now as per RFC 3036 and as
you said we should do exact match for the FEC <snip>
 
An implementor might decide to incorporate a delay prior to making this 
check, in
order to eliminate some potential race conditions.  And implementors may

disagree
as to what it means for LSR-1 to have an entry.  But - bottom line - if 
the check
for an exact match between FEC and route entry finds that such an entry 
does not
exist in an LSR, the corresponding label must not be used.

The procedures for handling label mappings are - in part - intended to 
provide for
robustness in the event that another LSR is not functioning properly.

Much of the discussion surrounding this question has been about complex 
things
an implementation might do.  None of these things are fundamentally 
incompatible
with the procedures as written.

[Pranjal]: Yes, there are certain things like introducing delay to
handle race condition as you said are implementer's choice. But I have
to follow the basic tenet now, that is the *exact* match for FEC
binding. 
--
Eric

Joel M. Halpern wrote:

  
The basic question is how much complication an implementation wishes 
to undertake to allow for the mismatch.
Note that such mismatches are rare.

As a local matter, an implementation can chose to create the FTN entry
    

  
for the exact match, and keep track of the relationship between that 
entry and the actual routing entry.  Eric has argued that such is 
undesirable complication.  I would tend to agree with him in the 
abstract.  What you choose to do in your implementation may depend 
upon your structures and on what problems you confront in the field.  
Creating the local entries and using them is legal.  Such entries 
would not affect routing advertisements.  They probably don't even 
effect label advertisements.

Yours,
Joel M. Halpern

At 04:45 PM 4/11/2006, Dutta, Pranjal wrote:

    
Thanks for the explanation on this.

Let me elaborate a scenario based on the rules that you mentioned.

For the procedure of label_map_received we have to apply both the
      
rules
  
1) and 2) right. For rule one, If Ru gets a label from Rd and Rd is
      
NOT
  
the next hop for the FEC. How Ru decides that the FEC is not next hop
are
a) FEC exactly matches a route entry but next hop is another LSR or
      
b)
  
As per your rule one FEC matches LPM to a shorter prefix P, and Rd is
not next hop for the matched prefix P. Lets say we hit issue b) and
      
due
  
to liberal retention at Ru it retains the label but will not be used
      
for
  
forwarding.

Now let's say that routing at Ru changes and now Rd becomes next hop
      
for
  
Prefix P. So now Ru should introduce an entry for the FEC into
forwarding table and install the NHLFE entry right? But that violates
your Rule 2 then
as the exact match condition should be met. If we apply rule 2 now,
      
then
  
we shouldn't use the label from Rd although Rd has become the next
      
hop
  
for Prefix P. Please correct me if I am wrong in this.

Regards,
Pranjal

-----Original Message-----
From: Joel M. Halpern [mailto:joel@stevecrocker.com]
Sent: Tuesday, 11 April, 2006 7:53 PM
To: Dutta, Pranjal
Cc: mpls@ietf.org
Subject: Re: [mpls] One LDP Implementation specific question of
      
receive
  
label mapping for prefix FECs

I think that there may be a better way to explain this.  There are
several different factors at work:

1) A received LDP label MUST NOT be used if the neighbor sending the
label is not the next hop for the FEC.  This condition does not
require an exact match in the forwarding table.
2) A Received label MUST NOT be used for packets which do not match
the received FEC.  This condition requires an exact match in the
forwarding table.

This does allow an implementation to create an exact match entry in
the forwarding table to select packets that use the label, even if
routing provided a shorter prefix.  This does allow one to use /32
entries without injecting those /32s into the actual routing
protocol.  However, the most common uses of .LDP (even with /32s)
will result in the entries being in the forwarding table anyway.

Another way to look at the condition above is that condition 1 is a
restriction on the use of a received label advertisement.  LPM check
is suitable.  Condition 2 is a restriction on the contents of the
Forwarding-Table-to-Next-hop-label-forwarding-entry that one
creates.  That must be an exact match.

Yours,
Joel M. Halpern

At 07:02 AM 4/11/2006, Eric W Gray wrote:
      
The implementation MUST do an exact match, as downstream LSRs will
forward based
only on the label.  Because they do not (typically) perform a route
look-up on the label
encapsulated inner IP packet, there is no reason to expect a
downstream LSR to be able
to separate a flow based on longest match when the routes further
downstream are distinct
for "longer matches".

Dutta, Pranjal wrote:

        
Hi Eric,
          As per RFC 3036 Label mapping receive procedures, when
          
Ru
  
received a label mapping from Rd for a FEC x, Ru need to find an
          
"exact"
      
match of the FEC x(IPv4/V6 prefix) in its route table. In
          
Inter-IGP-area
      
or inter-AS case the routes from Rd would be summarized to Ru and
          
in
  
such a case Ru MAY not find the exact match for such FEC x. In
          
terms
  
of
      
RFC 3036 then Ru MAY not find exact match for the FEC received from
          
Rd
  
in its route table and no further action at Ru. My question was why
          
Ru
  
can't we do a longest prefix match for the FEC x as LPM means it
          
can
  
be
      
reached by a downstream Rd?

Thanks,
Pranjal
          

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
--------------050305020900080005040502-- --===============0824086677== 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 --===============0824086677==-- From mpls-bounces@lists.ietf.org Thu Apr 13 10:06:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU2QY-0003Zd-Dx; Thu, 13 Apr 2006 10:04:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU2QW-0003ZY-J0 for mpls@ietf.org; Thu, 13 Apr 2006 10:04:04 -0400 Received: from imo-d01.mx.aol.com ([205.188.157.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU2QV-0005c2-WC for mpls@ietf.org; Thu, 13 Apr 2006 10:04:04 -0400 Received: from ewgray2k@netscape.net by imo-d01.mx.aol.com (mail_out_v38_r7.3.) id 6.1f.14c407d8 (22680); Thu, 13 Apr 2006 10:03:57 -0400 (EDT) Received: from [192.168.3.101] (c-24-128-207-21.hsd1.nh.comcast.net [24.128.207.21]) by air-in04.mx.aol.com (v108_r3.6) with ESMTP id MAILININ41-5898443e5a4c11d; Thu, 13 Apr 2006 10:03:56 -0400 Message-ID: <443E5A20.6010507@netscape.net> Date: Thu, 13 Apr 2006 10:03:12 -0400 From: Eric W Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: DECRAENE Bruno RD-CORE-ISS Subject: Re: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs References: <5A0FF108221C7C4E85738678804B567C032CD625@ftrdmel3.rd.francetelecom.fr> In-Reply-To: <5A0FF108221C7C4E85738678804B567C032CD625@ftrdmel3.rd.francetelecom.fr> X-AOL-IP: 24.128.207.21 X-Mailer: Unknown (No Version) X-Spam-Flag: NO X-Spam-Score: 0.1 (/) X-Scan-Signature: 81ca0cebdb446e1ff4e2b634791f24a9 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@GraIyMage.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0881456635==" Errors-To: mpls-bounces@lists.ietf.org --===============0881456635== Content-Type: multipart/alternative; boundary="------------060109050204070807030206" --------------060109050204070807030206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruno, No, if anything specific had to be said, it would be that Ru MUST NOT advertise a more specific FEC to an upstream peer (Ruu in this case) than it has advertised in routing. I cannot speak - obviously - for every implementation out there, but here's how I believe they _should_ work when dealing with an ABR (or other sumarization point): o The ABR-LSR advertises summarized routes into an adjacent Area. o The ABR-LSR distributes labels corresponding to those routes to LDP peers adjacent to it in that same Area. o The ABR-LSR is then the egress for the corresponding LSPs, in those cases where it has downstream routing entries corresponding to more specific routes. o The ABR-LSR MAY - at that point - inject arriving packets on downstream LSPs - after it performs a routing look-up and discovers an FTN (thus determing an appropriate label and outgoing interface). As I mentioned to Pranjal, this is defined this way for scalability reasons. It is not the intention of MPLS generally to eliminate the need for routing capability in the network at a cost of introducing unscalably large numbers of label distributions throughout the same network. Just as an opinion, a device that is incapable of making this kind of routing decision, has no business being in a position to summarize routes. -- Eric DECRAENE Bruno RD-CORE-ISS wrote: >Eric, > >Thanks for your comments. > >Additional discussions inlined. > >Regards, >Bruno > > > >>-----Original Message----- >>...[SNIP]... >> >> <>presumably the only thing at issue is Ru should label an IP packet >> that it receives. > > >[Bruno D:] A subsequent issue, is that to continue the LSP further >upstream, Ru should allocate a new label and advertise the specific FEC >upstream to Ruu. > > > >>What will happen is that the IP packet gets sent unlabeled to Rd >>which then labels it according to the specific route which is the best >> >> >match > > >>to the packet's IP destination address. >> >> > >[Bruno D:] That is indeed the current behavior but the problem is that >Rd may not be able to forward the IP packet (eg Ru is a VPN PE and Rd is >a P). And this may not be an IP packet BTW. > > > >>The label imposition procedure here is: >> >>- get the IP destination address >>- find the prefix in the routing table which is the best match >> >> >(longest > > >> match) for that destination address >>- use the label which was assigned to that prefix by the LSR which >> >> >routing > > >> says is the next hop for that prefix. >> >>It doesn't make sense for Rd to bind labels to prefixes which >> >> >are more > > >>specific than the one in the routing table, as the label >> >> >imposition > > >>procedure will never make use of such labels. >> >>I don't think we want to allow LDP to put prefixes in the routing >> >> >table, or > > >>else we'd have to treat it as a second routing algorithm and that >> >> >would > > >>raise all kinds of issues. >> >> > >[Bruno D:] Such procedure would not change the behavior of the IGP and >LDP. >LDP would definitely not act as a routing protocol and all routing >decisions (next-hop selection, recheability) would still rely on the >IGP. LDP would continue advertising labels for FECs and would entirely >rely on the RIB for setting up LSPs along the IP route. > >However, as you very correctly pointed out, we would allow LDP to >"de-aggregate" the FIB and this may raise some issue. However, what is >the difference, from the FIB point of view, between one /30 pointing to >Rd and four /32 pointing to Rd? I believe some FIB implementation >already represent a /30 as four /32. > >Besides, if populating the FTN with specific FEC is found to be an >issue, we can only populate the ILM on all P routers. For PE/ingress >router, all we really need is BGP to be aware of these LSPs and be able >to use them to reach the BGP Next Hops. > > > >>It is possible though to imagine a different imposition procedure: >> >>- get the IP destination address, A >> >>- find the prefix, P, in the routing table which is the best match >> >> >(longest > > >> match) for that destination address >> >>- get the next hop, N, for P, as specified by routing >> >>- if N has distributed any label bindings for prefixes which are >> >> >longer than > > >> P but begin with the same sequence of bits as P, and if any of >> >> >these, say > > >> Q, is a better match for A than P, then use the label which N >> >> >assigned to > > >> Q. >> >>This is a complicated procedure, though. You can't just match A >> >> >against Q, > > >>because there might be some prefix R in the routing table, with a >> >> >different > > >>next hop, which is a better match for A than P is, but not as good a >> >> >match > > >>as Q. The above imposition procedure says that the next hop for the >> >> >packet > > >>is determined by the route to R not by the route to P (or Q). >> >> >It's a > > >>complex matter to keep the forwarding tables in proper shape, >> >> >given that > > >>prefixes like Q can come and go asynchronously. >> >> > >[Bruno D:] I don't think there is a need to change the imposition >procedure at all. The modification of the label mapping procedure seems >enough. However, as pointing out by Dutta, an additional effort is >needed to sync LDP with the RIB because as you said, more specific >prefixes can come and go. > > > > >>There are other complications as well. For example, what do you do >> >> >if you > > >>get a packet which is labeled for Q, but the next hop has changed >> >> >and the > > >>new next hop has not distributed a label for Q? >> >>I suppose we could figure all this out if there were an actual problem >> >> >which > > >>didn't have a better solution. >> >> >> >> >> >> >> >>_______________________________________________ >>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 > > > > > --------------060109050204070807030206 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bruno,

    No, if anything specific had to be said, it would be that Ru MUST NOT advertise a more
specific FEC to an upstream peer (Ruu in this case) than it has advertised in routing.

    I cannot speak - obviously - for every implementation out there, but here's how I believe
they _should_ work when dealing with an ABR (or other sumarization point):

    o   The ABR-LSR advertises summarized routes into an adjacent Area.
    o   The ABR-LSR distributes labels corresponding to those routes to LDP
          peers adjacent to it in that same Area.
    o   The ABR-LSR is then the egress for the corresponding LSPs,  in those
          cases where it has downstream routing entries corresponding to more
          specific routes.
    o   The ABR-LSR MAY - at that point - inject arriving packets on downstream
          LSPs - after it performs a routing look-up and discovers an FTN (thus
          determing an appropriate label and outgoing interface).

    As I mentioned to Pranjal, this is defined this way for scalability reasons.  It is not the
intention of MPLS generally to eliminate the need for routing capability in the network at
a cost of introducing unscalably large numbers of label distributions throughout the same
network.

    Just as an  opinion, a device that is incapable of making this kind of routing decision,
has no business being in a position to summarize routes.

--
Eric

DECRAENE Bruno RD-CORE-ISS wrote:
Eric,

Thanks for your comments.

Additional discussions inlined.

Regards,
Bruno

  
-----Original Message-----
...[SNIP]...
<>presumably the only thing at issue is Ru should label an IP packet that it receives. 

[Bruno D:] A subsequent issue, is that to continue the LSP further
upstream, Ru should allocate a new label and advertise the specific FEC
upstream to Ruu.

  
What will happen is that  the IP packet gets sent unlabeled to Rd
which then labels it according to the specific route which is the best
    
match
  
to the packet's IP destination address.
    

[Bruno D:] That is indeed the current behavior but the problem is that
Rd may not be able to forward the IP packet (eg Ru is a VPN PE and Rd is
a P). And this may not be an IP packet BTW.
 
  
The label imposition procedure here is:

- get the IP destination address
- find  the prefix  in the routing  table which  is the best  match
    
(longest
  
  match) for that destination address
- use the label  which was assigned to that prefix by  the LSR which
    
routing
  
  says is the next hop for that prefix.

It  doesn't make sense  for Rd  to bind  labels to  prefixes which
    
are more
  
specific  than  the  one in  the  routing  table,  as the  label
    
imposition
  
procedure will never make use of such labels.

I don't think we want to allow  LDP to put prefixes in the routing
    
table, or
  
else we'd  have to  treat it as  a second  routing algorithm and  that
    
would
  
raise all kinds of issues.
    

[Bruno D:] Such procedure would not change the behavior of the IGP and
LDP.
LDP would definitely not act as a routing protocol and all routing
decisions (next-hop selection, recheability) would still rely on the
IGP. LDP would continue advertising labels for FECs and would entirely
rely on the RIB for setting up LSPs along the IP route.

However, as you very correctly pointed out, we would allow LDP to
"de-aggregate" the FIB and this may raise some issue. However, what is
the difference, from the FIB point of view, between one /30 pointing to
Rd and four /32 pointing to Rd? I believe some FIB implementation
already represent a /30 as four /32.

Besides, if populating the FTN with specific FEC is found to be an
issue, we can only populate the ILM on all P routers. For PE/ingress
router, all we really need is BGP to be aware of these LSPs and be able
to use them to reach the BGP Next Hops.

  
It is possible though to imagine a different imposition procedure:

- get the IP destination address, A

- find the prefix, P, in the routing table which is the best match
    
(longest
  
  match) for that destination address

- get the next hop, N, for P, as specified by routing

- if N has distributed any label bindings for prefixes which are
    
longer than
  
  P but begin with the same sequence of  bits as P, and if any of
    
these, say
  
  Q, is a better match for A than  P, then use the label which N
    
assigned to
  
  Q.

This is a complicated procedure, though.   You can't just match A
    
against Q,
  
because there might be some prefix  R in the routing table, with a
    
different
  
next hop, which is  a better match for A than P is, but  not as good a
    
match
  
as Q.  The above imposition procedure  says that the next hop for the
    
packet
  
is determined  by the  route to  R not  by the route  to P  (or Q).
    
It's a
  
complex matter  to keep  the forwarding tables  in proper shape,
    
given that
  
prefixes like Q can come and go asynchronously.
    

[Bruno D:] I don't think there is a need to change the imposition
procedure at all. The modification of the label mapping procedure seems
enough. However, as pointing out by Dutta, an additional effort is
needed to sync LDP with the RIB because as you said, more specific
prefixes can come and go.

 
  
There are other  complications as well.  For example, what do  you do
    
if you
  
get a packet  which is labeled for Q,  but the next hop has  changed
    
and the
  
new next hop has not distributed a label for Q?

I suppose we could figure all this out if there were an actual problem
    
which
  
didn't have a better solution.







_______________________________________________
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
--------------060109050204070807030206-- --===============0881456635== 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 --===============0881456635==-- From mpls-bounces@lists.ietf.org Thu Apr 13 10:21:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU2fO-0007jH-46; Thu, 13 Apr 2006 10:19:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU2fM-0007Yb-8B for mpls@ietf.org; Thu, 13 Apr 2006 10:19:24 -0400 Received: from imo-d01.mx.aol.com ([205.188.157.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU2fM-0006Cx-1q for mpls@ietf.org; Thu, 13 Apr 2006 10:19:24 -0400 Received: from ewgray2k@netscape.net by imo-d01.mx.aol.com (mail_out_v38_r7.3.) id 6.1b1.117afad3 (22682); Thu, 13 Apr 2006 10:17:34 -0400 (EDT) Received: from [192.168.3.101] (c-24-128-207-21.hsd1.nh.comcast.net [24.128.207.21]) by air-in04.mx.aol.com (v108_r3.6) with ESMTP id MAILININ43-589a443e5d7c2c4; Thu, 13 Apr 2006 10:17:33 -0400 Message-ID: <443E5D50.7090604@netscape.net> Date: Thu, 13 Apr 2006 10:16:48 -0400 From: Eric W Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: DECRAENE Bruno RD-CORE-ISS , pdutta@riverstonenet.com Subject: Re: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs References: <5A0FF108221C7C4E85738678804B567C032CD625@ftrdmel3.rd.francetelecom.fr> In-Reply-To: <5A0FF108221C7C4E85738678804B567C032CD625@ftrdmel3.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 24.128.207.21 X-Mailer: Unknown (No Version) X-Spam-Flag: NO X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: mpls-bounces@lists.ietf.org Bruno/Pranjal, One thing I would like to make perfectly clear in this discussion is that - if either or both of you would like to write an ID that proposes changing or extending LDP to do what you suggest, you should do so. The suggestions you make may be well received by participants in the MPLS working group. However, you should not view this as something to "correct" in the current LDP specification. The point of the current LDP specification work is to document what is being done in current interoperable implementations, now. I believe the point has been sufficiently well made by now that the text - as is - represents current implementation better than the changes you've implied or explicitly suggested should be made with respect to the exact match requirement in handling an arriving label distribution. -- Eric _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Apr 13 10:31:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU2p1-0000E7-QI; Thu, 13 Apr 2006 10:29:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU2p0-0000AI-I7 for mpls@ietf.org; Thu, 13 Apr 2006 10:29:22 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU2oy-0006RX-Se for mpls@ietf.org; Thu, 13 Apr 2006 10:29:22 -0400 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k3DETBY00458; Thu, 13 Apr 2006 10:29:11 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] One LDP Implementation specific question ofreceive labelmapping for prefix FECs Date: Thu, 13 Apr 2006 10:28:58 -0400 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE08A29B19@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] One LDP Implementation specific question ofreceive labelmapping for prefix FECs Thread-Index: AcZfBVLJIM28jcDqQouwk2EAqQgxLQAAFxWg From: "David Allan" To: , "DECRAENE Bruno RD-CORE-ISS" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org FYI It does go further, re-writing FEC stack processing for LSP ping to = permit interpretation and matching of more specific to less specific = prefixes and figuring out whether that was actually permissable in the = local context (a.k.a. more specific prefix did not exist at the = terminating LSR) could get truly ugly... cheers Dave > -----Original Message----- > From: Eric W Gray [mailto:ewgray2k@netscape.net]=20 > Sent: Thursday, April 13, 2006 10:17 AM > To: DECRAENE Bruno RD-CORE-ISS; pdutta@riverstonenet.com > Cc: mpls@ietf.org > Subject: Re: [mpls] One LDP Implementation specific question=20 > ofreceive labelmapping for prefix FECs >=20 >=20 > Bruno/Pranjal, >=20 > One thing I would like to make perfectly clear in this=20 > discussion is=20 > that - if either or > both of you would like to write an ID that proposes changing or=20 > extending LDP to do > what you suggest, you should do so. The suggestions you make may be=20 > well received > by participants in the MPLS working group. >=20 > However, you should not view this as something to=20 > "correct" in the=20 > current LDP > specification. The point of the current LDP specification work is to=20 > document what is > being done in current interoperable implementations, now.=20 >=20 > I believe the point has been sufficiently well made by=20 > now that the=20 > text - as is - > represents current implementation better than the changes=20 > you've implied=20 > or explicitly > suggested should be made with respect to the exact match=20 > requirement in=20 > handling an > arriving label distribution. >=20 > -- > Eric >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Apr 13 10:41:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU2yQ-0005JV-Nq; Thu, 13 Apr 2006 10:39:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU2yO-0005IP-Lt for mpls@lists.ietf.org; Thu, 13 Apr 2006 10:39:04 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU2yN-00071Z-Sh for mpls@lists.ietf.org; Thu, 13 Apr 2006 10:39:04 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1FU2yb-0002fi-00 for mpls@lists.ietf.org; Thu, 13 Apr 2006 15:39:17 +0100 Received: from Puppy ([217.158.132.33] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 15:39:30 +0100 Message-ID: <123f01c65f08$0aea4460$bf849ed9@Puppy> From: "Adrian Farrel" To: , References: Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-lsp-ping-01.txt Date: Thu, 13 Apr 2006 15:37:59 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 13 Apr 2006 14:39:32.0062 (UTC) FILETIME=[13A55FE0:01C65F08] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0761727316==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0761727316== Content-Type: multipart/alternative; boundary="----=_NextPart_000_123C_01C65F10.3E7B6EF0" This is a multi-part message in MIME format. ------=_NextPart_000_123C_01C65F10.3E7B6EF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ben, > 1) Why is it restricted to P2MP TE LSPs? mLDP signalled > LSPs will also require OAM and it's not clear to me why=20 > they have been precluded by this draft. Well, this draft does *not* preclude mLDP. There are some factors to consider. a. When this draft was started, mLDP did not exist b. When this draft was developed there were two competing=20 mLDP solutions drafts and no clear definition of mLDP FECs. c. The existing MPLS-TE P2MP techniques are extensible (by use of a FEC) but it is not clear that the problem=20 space is the same with regard to scalability for mLDP. In particular, the ingress of an mLDP tree is (perhaps) not aware of the identities of the egresses and so it is hard to ping a single egress along the tree. d. What would be wrong about having two drafts for this? Actually, at the last couple of IETFs (and on the list, if I recall) I = have asked the question about whether to roll this all into one I-D or = to keep it separate, and I have not had anything in the way of an = answer.=20 At the moment, we are inclined to keep the two pieces of work separate = for cleanliness. But doing so does not imply that anyone thinks that = mLDP should be without OAM. > 2) Section 4.1 of draft-ietf-mpls-p2mp-oam-reqs-01 states=20 > "The ability to detect defects in a P2MP LSP SHOULD not > require manual, hop-by-hop troubleshooting of each LSR=20 > used to switch traffic for that LSP, and SHOULD rely on > proactive OAM procedures (such as continuous path > connectivity and SLA measurement mechanisms)." whereas > the comments in draft-ietf-mpls-p2mp-lsp-ping-01 imply > to me that proactive/continuous OAM may not be possible > with the proposed solution due to scaling concerns > resulting from the possibility of flooding the ingress > with responses. Hmmm. May be there are some semantics around "proactive" and "continuous". I think that these terms could be taken to mean that you should be able = to initiate a "probe" at the ingress and rely on the probe mechanism to = determine the existence of and location of the defect. This should = happen without the operator having to initiate a probe hop-by-hop = through the network along the path of the LSP. But we should also take into account that the proposed P2MP LSP Ping is = not intended to be a solution for all requirements in the P2MP OAM = Requirements I-D. Indeed, section 4.1 of the P2MP OAM Requirements I-D = is quite clear about the issues of using LSP Ping for defect detection = (compared with section 4.2 that describes defect diagnosis). Whether some other mechanism needs to be added to the toolkit (compare = with BFD for P2P LSPs) for error detection is up for grabs, and I am = sure that the working group would welcome contributions. > As well as the ability to delay/jitter > the echo responses has consideration been given to other > potential ways to improve scalability for example using a > Nack model for responses, somehow aggregating responses > etc.? We did discuss a Nack model. I am not sure if it is what you are talking = about. In brief we considered... - OAM is enabled (see later) - Egress expects to receive "ping" every time unit - In the absence of a "ping" the egress sends an alert We felt that OAM should not be permanently active on what may be a low = bandwidth service for fear of being the main consumer of traffic. = Therefore, OAM must be enabled by an explicit act (and not implicitly = enabled by the establishment of the LSP). Thus, we can say that OAM is enabled by the first ping. We would, of = course, need a positive ack to that event. After that, we can resort to = Nack processing. But I think there is some handshaking needed to make = sure that the positive ack has been received. Disabling is more of a worry. If the disable instruction does not reach = an egress, it will continue to generate Nacks. Thus we would need some = form of back-off on Nacks dropping quite quickly to assuming that OAM is = disabled. All of this is achievable, and could be built on top of LSP ping, but = what is the cost/benefit? It is certainly a more complicated process, = and I don't hear anyone suggesting that they plan to implement it. But = if someone is working on such a solution, I'm sure we'd be happy to fold = it in to our draft. Aggregation of responses was also briefly discussed. We have two = problems with this. 1. How does the transit node know how long to hold on to a response in = the hope that another will come along? In fact, won't any delay for = aggregation simply serve to destroy the benefits of jitter? 2. What makes us assume that responses will follow paths that make = aggregation practical? Cheers, Adrian ------=_NextPart_000_123C_01C65F10.3E7B6EF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Ben,
 
> 1) Why is it restricted to P2MP = TE=20 LSPs?  mLDP signalled
> LSPs will also require OAM = and it's not=20 clear to me why
> they have been precluded by this = draft.
 
Well, this draft does *not* preclude=20 mLDP.
There are some factors to = consider.
a. When this draft was started, mLDP = did not=20 exist
b. When this draft was developed = there were two=20 competing
    mLDP solutions = drafts and no=20 clear definition of mLDP
   FECs.
c. The existing MPLS-TE P2MP = techniques are=20 extensible
    (by use of a FEC) = but it is=20 not clear that the problem
    space is the same = with regard=20 to scalability for mLDP.
    In particular, the = ingress of=20 an mLDP tree is (perhaps)
    not aware of the = identities of=20 the egresses and so it is
    hard to ping a = single egress=20 along the tree.
d. What would be wrong about having = two drafts=20 for this?
 
Actually, at the last couple of IETFs = (and on the=20 list, if I recall) I have asked the question about whether to roll this = all into=20 one I-D or to keep it separate, and I have not had anything in the way = of an=20 answer.
 
At the moment, we are inclined to = keep the two=20 pieces of work separate for cleanliness. But doing so does not imply = that anyone=20 thinks that mLDP should be without OAM.

> 2) Section 4.1 of = draft-ietf-mpls-p2mp-oam-reqs-01=20 states
> "The ability to detect defects in a P2MP LSP SHOULD not
> require manual, hop-by-hop troubleshooting of each LSR =
> used to switch traffic for that LSP, and SHOULD rely on
> proactive = OAM procedures (such as continuous path
> connectivity and = SLA measurement mechanisms)." = whereas
> the comments=20 in draft-ietf-mpls-p2mp-lsp-ping-01 imply
> to me = that proactive/continuous OAM may not be = possible
> with the proposed solution due to scaling concerns
> resulting from the = possibility of=20 flooding the ingress
> with = responses.
 
Hmmm.
May be there are some semantics = around=20 "proactive" and "continuous".
I think that these terms could be = taken to mean=20 that you should be able to initiate a "probe" at the ingress and rely=20 on the probe mechanism to determine the existence of and location = of the=20 defect. This should happen without the operator having to initiate a = probe=20 hop-by-hop through the network along the path of the LSP.
 
But we should also take into account = that the=20 proposed P2MP LSP Ping is not intended to be a solution for all = requirements in=20 the P2MP OAM Requirements I-D. Indeed, section 4.1 of the P2MP OAM = Requirements=20 I-D is quite clear about the issues of using LSP Ping for defect = detection=20 (compared with section 4.2 that describes defect = diagnosis).
 
Whether some other mechanism needs to = be added to=20 the toolkit (compare with BFD for P2P LSPs) for error detection is up = for grabs,=20 and I am sure that the working group would welcome = contributions.
 
> As well as the ability to = delay/jitter
> the echo responses has = consideration=20 been given to other
> potential ways to improve = scalability=20 for example using a
> Nack model for responses, = somehow=20 aggregating responses
> etc.?
We did discuss a Nack model. I am not = sure if it=20 is what you are talking about.
In brief we considered...
- OAM is enabled (see later)
- Egress expects to receive "ping" every time unit
- In the absence of a "ping" the egress sends an alert
 
We felt that OAM should not be permanently active on what may be a = low=20 bandwidth service for fear of being the main consumer of traffic. = Therefore, OAM=20 must be enabled by an explicit act (and not implicitly enabled by the=20 establishment of the LSP).
 
Thus, we can say that OAM is enabled by the first ping. We would, = of=20 course, need a positive ack to that event. After that, we can resort to = Nack=20 processing. But I think there is some handshaking needed to make sure = that the=20 positive ack has been received.
 
Disabling is more of a worry. If the disable instruction does not = reach an=20 egress, it will continue to generate Nacks. Thus we would need some form = of=20 back-off on Nacks dropping quite quickly to assuming that OAM is = disabled.
 
All of this is achievable, and could be built on top of LSP ping, = but what=20 is the cost/benefit? It is certainly a more complicated process, and I = don't=20 hear anyone suggesting that they plan to implement it. But if someone is = working=20 on such a solution, I'm sure we'd be happy to fold it in to our = draft.
 
 
Aggregation of responses was also briefly discussed. We have two = problems=20 with this.
 
1. How does the transit node know how long to hold on to a response = in the=20 hope that another will come along? In fact, won't any delay for = aggregation=20 simply serve to destroy the benefits of jitter?
 
2. What makes us assume that responses will follow paths that make=20 aggregation practical?
 
 
Cheers,
Adrian
------=_NextPart_000_123C_01C65F10.3E7B6EF0-- --===============0761727316== 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 --===============0761727316==-- From mpls-bounces@lists.ietf.org Thu Apr 13 10:45:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU32m-0008QN-TW; Thu, 13 Apr 2006 10:43:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU32k-0008QG-RJ for mpls@ietf.org; Thu, 13 Apr 2006 10:43:34 -0400 Received: from wproxy.gmail.com ([64.233.184.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU32k-0007Ax-7J for mpls@ietf.org; Thu, 13 Apr 2006 10:43:34 -0400 Received: by wproxy.gmail.com with SMTP id i34so1491591wra for ; Thu, 13 Apr 2006 07:43:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=gYNCu6NnZdE8Fg71Edc/FxBN3v34/SpuJsuSNx1g5vgAPz4sQ/YXmoUpEBPRnEzTBCFOHtQ8DrKIzKa7dN1CAseYBIaaaCwaPHR1259FYHi70LhDidNYeb+XXXBCYLMVSo0Ovwx1DCZHVBqXQ1O5Z6K2qRFllrt8m24pjH64fB0= Received: by 10.54.111.3 with SMTP id j3mr514676wrc; Thu, 13 Apr 2006 07:43:32 -0700 (PDT) Received: by 10.54.123.11 with HTTP; Thu, 13 Apr 2006 07:43:32 -0700 (PDT) Message-ID: <70452ae70604130743n43c6c5b5ia6eace80b4193773@mail.gmail.com> Date: Thu, 13 Apr 2006 10:43:32 -0400 From: "Raveendra Torvi" To: ewgray@graiymage.com Subject: Re: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs In-Reply-To: <443E5A20.6010507@netscape.net> MIME-Version: 1.0 References: <5A0FF108221C7C4E85738678804B567C032CD625@ftrdmel3.rd.francetelecom.fr> <443E5A20.6010507@netscape.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5df1f98f3253c63b673ea560243aa58f Cc: DECRAENE Bruno RD-CORE-ISS , 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="===============1417892300==" Errors-To: mpls-bounces@lists.ietf.org --===============1417892300== Content-Type: multipart/alternative; boundary="----=_Part_7673_3165647.1144939412564" ------=_Part_7673_3165647.1144939412564 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Eric, According to your solution LSPs are broken at the aggregation boundary or IGP area boundary, which may not be desirable in case of all-MPLS network. If main goal is to carry transit traffic by the way of LDP-MPLS switching , In case of all-MPLS networks an operator would like to inject only LDP-FECs in other areas (hence achieve the scalability) or avoid summarization LDP-FECs at IGP area boundary .. Please help me understand. Ravi. On 4/13/06, Eric W Gray wrote: > > Bruno, > > No, if anything specific had to be said, it would be that Ru MUST NOT > advertise a more > specific FEC to an upstream peer (Ruu in this case) than it has advertise= d > in routing. > > I cannot speak - obviously - for every implementation out there, but > here's how I believe > they _should_ work when dealing with an ABR (or other sumarization point)= : > > o The ABR-LSR advertises summarized routes into an adjacent Area. > o The ABR-LSR distributes labels corresponding to those routes to > LDP > peers adjacent to it in that same Area. > o The ABR-LSR is then the egress for the corresponding LSPs, in > those > cases where it has downstream routing entries corresponding to > more > specific routes. > o The ABR-LSR MAY - at that point - inject arriving packets on > downstream > LSPs - after it performs a routing look-up and discovers an FTN > (thus > determing an appropriate label and outgoing interface). > > As I mentioned to Pranjal, this is defined this way for scalability > reasons. It is not the > intention of MPLS generally to eliminate the need for routing capability > in the network at > a cost of introducing unscalably large numbers of label distributions > throughout the same > network. > > Just as an opinion, a device that is incapable of making this kind o= f > routing decision, > has no business being in a position to summarize routes. > > -- > Eric > > > DECRAENE Bruno RD-CORE-ISS wrote: > > Eric, > > Thanks for your comments. > > Additional discussions inlined. > > Regards, > Bruno > > -----Original Message----- > ...[SNIP]... > > <>presumably the only thing at issue is Ru should label an IP packet tha= t > it receives. > > [Bruno D:] A subsequent issue, is that to continue the LSP further > upstream, Ru should allocate a new label and advertise the specific FEC > upstream to Ruu. > > What will happen is that the IP packet gets sent unlabeled to Rd > which then labels it according to the specific route which is the best > > match > > to the packet's IP destination address. > > [Bruno D:] That is indeed the current behavior but the problem is that > Rd may not be able to forward the IP packet (eg Ru is a VPN PE and Rd is > a P). And this may not be an IP packet BTW. > > The label imposition procedure here is: > > - get the IP destination address > - find the prefix in the routing table which is the best match > > (longest > > match) for that destination address > - use the label which was assigned to that prefix by the LSR which > > routing > > says is the next hop for that prefix. > > It doesn't make sense for Rd to bind labels to prefixes which > > are more > > specific than the one in the routing table, as the label > > imposition > > procedure will never make use of such labels. > > I don't think we want to allow LDP to put prefixes in the routing > > table, or > > else we'd have to treat it as a second routing algorithm and that > > would > > raise all kinds of issues. > > [Bruno D:] Such procedure would not change the behavior of the IGP and > LDP. > LDP would definitely not act as a routing protocol and all routing > decisions (next-hop selection, recheability) would still rely on the > IGP. LDP would continue advertising labels for FECs and would entirely > rely on the RIB for setting up LSPs along the IP route. > > However, as you very correctly pointed out, we would allow LDP to > "de-aggregate" the FIB and this may raise some issue. However, what is > the difference, from the FIB point of view, between one /30 pointing to > Rd and four /32 pointing to Rd? I believe some FIB implementation > already represent a /30 as four /32. > > Besides, if populating the FTN with specific FEC is found to be an > issue, we can only populate the ILM on all P routers. For PE/ingress > router, all we really need is BGP to be aware of these LSPs and be able > to use them to reach the BGP Next Hops. > > It is possible though to imagine a different imposition procedure: > > - get the IP destination address, A > > - find the prefix, P, in the routing table which is the best match > > (longest > > match) for that destination address > > - get the next hop, N, for P, as specified by routing > > - if N has distributed any label bindings for prefixes which are > > longer than > > P but begin with the same sequence of bits as P, and if any of > > these, say > > Q, is a better match for A than P, then use the label which N > > assigned to > > Q. > > This is a complicated procedure, though. You can't just match A > > against Q, > > because there might be some prefix R in the routing table, with a > > different > > next hop, which is a better match for A than P is, but not as good a > > match > > as Q. The above imposition procedure says that the next hop for the > > packet > > is determined by the route to R not by the route to P (or Q). > > It's a > > complex matter to keep the forwarding tables in proper shape, > > given that > > prefixes like Q can come and go asynchronously. > > [Bruno D:] I don't think there is a need to change the imposition > procedure at all. The modification of the label mapping procedure seems > enough. However, as pointing out by Dutta, an additional effort is > needed to sync LDP with the RIB because as you said, more specific > prefixes can come and go. > > > There are other complications as well. For example, what do you do > > if you > > get a packet which is labeled for Q, but the next hop has changed > > and the > > new next hop has not distributed a label for Q? > > I suppose we could figure all this out if there were an actual problem > > which > > didn't have a better solution. > > > > > > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.orghttps://www1.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.orghttps://www1.ietf.org/mailman/listinfo/mpls > > > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > > > -- 101 Billerica Ave, N.Billerica MA -01862 ------=_Part_7673_3165647.1144939412564 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Eric,
According to your solution  LSPs are broken at the aggregatio= n boundary or IGP area boundary, which may not be desirable in case of all-= MPLS network. If main goal is to carry transit traffic by the way of LDP-MP= LS switching , In case of all-MPLS networks an operator would like to injec= t only LDP-FECs in other areas (hence achieve the scalability) or avoid sum= marization LDP-FECs at IGP area boundary .. Please help me understand.=20
Ravi.


On 4/13/06, Eric W Gray <ewgray2k@netscape.net> wrote:
=20 =20 Bruno,

    No, if anything specific had to be said, it would be tha= t Ru MUST NOT advertise a more
specific FEC to an upstream peer (Ruu in this case) than it has advertised in routing.

    I cannot speak - obviously - for every implementation ou= t there, but here's how I believe
they _should_ work when dealing with an ABR (or other sumarization point):

    o   The ABR-LSR advertises summarized routes i= nto an adjacent Area.
    o   The ABR-LSR distributes labels correspondi= ng to those routes to LDP
          peers adjacent to it in that s= ame Area.
    o   The ABR-LSR is then the egress for the cor= responding LSPs,  in those
          cases where it has downstream = routing entries corresponding to more
          specific routes.
    o   The ABR-LSR MAY - at that point - inject a= rriving packets on downstream
          LSPs - after it performs = a routing look-up and discovers an FTN (thus
          determing an appropriate label= and outgoing interface).

    As I mentioned to Pranjal, this is defined this way for = scalability reasons.  It is not the
intention of MPLS generally to eliminate the need for routing capability in the network at
a cost of introducing unscalably large numbers of label distributions throughout the same
network.

    Just as an  opinion, a device that is incapable of = making this kind of routing decision,
has no business being in a position to summarize routes.

--
Eric


DECRAENE Bruno RD-CORE-ISS wrote:
Eric,

Thanks for your comments.

Additional discussions=
 inlined.

Regards,
Bruno

  
-----Original Message-----
...[SNIP]...
<>presumably the only thing at issue is Ru should label an IP packet that it receives. 
[Bruno D:] A subsequent issue, is that to continue the LSP furtherupstream, Ru should allocate a new label and advertise the specific FECupstream to Ruu.

  
What will happen is that  the IP packet gets sent unlabeled to Rd<=
br>which then labels it according to the specific route which is the best    
match
  
to the packet's IP destination address.
    
[Bruno D:] That is indeed the current behavior but the problem is th=
at
Rd may not be able to forward the IP packet (eg Ru is a VPN PE and Rd=
 is
a P). And this may not be an IP packet BTW.
 
  
The label imposition procedure here is:

- get the IP destin=
ation address
- find  the prefix  in the routing  table which  is the be=
st  match
    
(longest
  
  match) for that destination address
- use the label  which wa=
s assigned to that prefix by  the LSR which
    
routing
  
  says is the next hop for that prefix.

It  doesn't make se=
nse  for Rd  to bind  labels to  prefixes which
    
are more
  
specific  than  the  one in  the  routing  table,  as the  label    
imposition
  
procedure will never make use of such labels.

I don't think=
 we want to allow  LDP to put prefixes in the routing
    
table, or
  
else we'd  have to  treat it as  a second  routing algorithm and  =
that
    
would
  
raise all kinds of issues.
    
[Bruno D:] Such procedure would not change the behavior of the IGP a=
nd
LDP.
LDP would definitely not act as a routing protocol and all ro=
uting
decisions (next-hop selection, recheability) would still rely on t=
he

IGP. LDP would continue advertising labels for FECs and would entirely<=
br>rely on the RIB for setting up LSPs along the IP route.

However, =
as you very correctly pointed out, we would allow LDP to
"de-aggreg=
ate" the FIB and this may raise some issue. However, what is

the difference, from the FIB point of view, between one /30 pointing to=

Rd and four /32 pointing to Rd? I believe some FIB implementation
al=
ready represent a /30 as four /32.

Besides, if populating the FTN wi=
th specific FEC is found to be an

issue, we can only populate the ILM on all P routers. For PE/ingressrouter, all we really need is BGP to be aware of these LSPs and be ableto use them to reach the BGP Next Hops.

  
It is possible though to imagine a different imposition procedure:=


- get the IP destination address, A

- find the prefix, P, in=
 the routing table which is the best match
    
(longest
  
  match) for that destination address

- get the next hop, N=
, for P, as specified by routing

- if N has distributed any label bi=
ndings for prefixes which are
    
longer than
  
  P but begin with the same sequence of  bits as P, and if any of<=
br>    
these, say
  
  Q, is a better match for A than  P, then use the label which N    
assigned to
  
  Q.

This is a complicated procedure, though.   You can't j=
ust match A
    
against Q,
  
because there might be some prefix  R in the routing table, with a=

    
different
  
next hop, which is  a better match for A than P is, but  not as go=
od a
    
match
  
as Q.  The above imposition procedure  says that the next hop for =
the
    
packet
  
is determined  by the  route to  R not  by the route  to P  (or Q)=
.
    
It's a
  
complex matter  to keep  the forwarding tables  in proper shape,    
given that
  
prefixes like Q can come and go asynchronously.
    
[Bruno D:] I don't think there is a need to change the impositionprocedure at all. The modification of the label mapping procedure seemsenough. However, as pointing out by Dutta, an additional effort is

needed to sync LDP with the RIB because as you said, more specific
prefi=
xes can come and go.

 
  
There are other  complications as well.  For example, what do  you=
 do
    
if you
  
get a packet  which is labeled for Q,  but the next hop has  chang=
ed
    
and the
  
new next hop has not distributed a label for Q?

I suppose w=
e could figure all this out if there were an actual problem
    
which
  
didn't have a better solution.







____=
___________________________________________
mpls mailing list

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

mpls@lists.ietf.org
https://www1.ietf.o=
rg/mailman/listinfo/mpls

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





--
101 Billerica Ave,
N.Billerica MA -0= 1862
------=_Part_7673_3165647.1144939412564-- --===============1417892300== 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 --===============1417892300==-- From mpls-bounces@lists.ietf.org Thu Apr 13 11:45:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU3yp-0007EN-My; Thu, 13 Apr 2006 11:43:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU3yn-0007AT-It for mpls@ietf.org; Thu, 13 Apr 2006 11:43:33 -0400 Received: from imo-d01.mx.aol.com ([205.188.157.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU3ym-0000rC-Sf for mpls@ietf.org; Thu, 13 Apr 2006 11:43:33 -0400 Received: from ewgray2k@netscape.net by imo-d01.mx.aol.com (mail_out_v38_r7.3.) id o.e9.14d3128d (22681); Thu, 13 Apr 2006 11:43:26 -0400 (EDT) Received: from [192.168.3.101] (c-24-128-207-21.hsd1.nh.comcast.net [24.128.207.21]) by air-in04.mx.aol.com (v108_r3.6) with ESMTP id MAILININ42-5899443e719d23a; Thu, 13 Apr 2006 11:43:25 -0400 Message-ID: <443E7170.1010501@netscape.net> Date: Thu, 13 Apr 2006 11:42:40 -0400 From: Eric W Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Raveendra Torvi Subject: Re: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs References: <5A0FF108221C7C4E85738678804B567C032CD625@ftrdmel3.rd.francetelecom.fr> <443E5A20.6010507@netscape.net> <70452ae70604130743n43c6c5b5ia6eace80b4193773@mail.gmail.com> In-Reply-To: <70452ae70604130743n43c6c5b5ia6eace80b4193773@mail.gmail.com> X-AOL-IP: 24.128.207.21 X-Mailer: Unknown (No Version) X-Spam-Flag: NO X-Spam-Score: 0.1 (/) X-Scan-Signature: 7b4956e5f2f9c5fe16a8fbd4ddb538bc Cc: DECRAENE Bruno RD-CORE-ISS , mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@GraIyMage.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1472848090==" Errors-To: mpls-bounces@lists.ietf.org --===============1472848090== Content-Type: multipart/alternative; boundary="------------070002010802000104030700" --------------070002010802000104030700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Let me answer just the first part of this and let the rest take care of itself... :-) LSPs are [terminated] at aggregation boundaries. This may not be desirable in case of an all-MPLS network. To some extent, every box needs to "make up its mind" whether it is a router or a switch. It is important in interoperating between boxes that they are each self-consistent. The aggregator router could decide not to aggregate routing information. That way, it can distribute more specific labels and not worry about inconsistencies between the routes it has advertised and the labels it distributes. However, there are reasons why routers aggregate routing information, and I think it may be difficult to justify why those reasons would not apply equally well to label distribution. It may very well be the case that routing aggregation is not completely justified in specific deployment scenarios. In that case, perhaps it would simply be better to "turn off" route aggregation. -- Eric Raveendra Torvi wrote: > Eric, > According to your solution LSPs are broken at the aggregation > boundary or IGP area boundary, which may not be desirable in case of > all-MPLS network. If main goal is to carry transit traffic by the way > of LDP-MPLS switching , In case of all-MPLS networks an operator would > like to inject only LDP-FECs in other areas (hence achieve the > scalability) or avoid summarization LDP-FECs at IGP area boundary .. > Please help me understand. > Ravi. > > > On 4/13/06, Eric W Gray > wrote: > > Bruno, > > No, if anything specific had to be said, it would be that Ru > MUST NOT advertise a more > specific FEC to an upstream peer (Ruu in this case) than it has > advertised in routing. > > I cannot speak - obviously - for every implementation out > there, but here's how I believe > they _should_ work when dealing with an ABR (or other sumarization > point): > > o The ABR-LSR advertises summarized routes into an adjacent > Area. > o The ABR-LSR distributes labels corresponding to those > routes to LDP > peers adjacent to it in that same Area. > o The ABR-LSR is then the egress for the corresponding > LSPs, in those > cases where it has downstream routing entries > corresponding to more > specific routes. > o The ABR-LSR MAY - at that point - inject arriving packets > on downstream > LSPs - after it performs a routing look-up and discovers > an FTN (thus > determing an appropriate label and outgoing interface). > > As I mentioned to Pranjal, this is defined this way for > scalability reasons. It is not the > intention of MPLS generally to eliminate the need for routing > capability in the network at > a cost of introducing unscalably large numbers of label > distributions throughout the same > network. > > Just as an opinion, a device that is incapable of making this > kind of routing decision, > has no business being in a position to summarize routes. > > -- > Eric > > > DECRAENE Bruno RD-CORE-ISS wrote: > >Eric, > >Thanks for your comments. > >Additional discussions inlined. > >Regards, >Bruno > > > >>-----Original Message----- >>...[SNIP]... >> >> <>presumably the only thing at issue is Ru should label an IP >> packet that it receives. > >[Bruno D:] A subsequent issue, is that to continue the LSP further >upstream, Ru should allocate a new label and advertise the specific FEC >upstream to Ruu. > > > >>What will happen is that the IP packet gets sent unlabeled to Rd >>which then labels it according to the specific route which is the best >> >> >match > > >>to the packet's IP destination address. >> >> >[Bruno D:] That is indeed the current behavior but the problem is that >Rd may not be able to forward the IP packet (eg Ru is a VPN PE and Rd is >a P). And this may not be an IP packet BTW. > > > >>The label imposition procedure here is: >> >>- get the IP destination address >>- find the prefix in the routing table which is the best match >> >> >(longest > > >> match) for that destination address >>- use the label which was assigned to that prefix by the LSR which >> >> >routing > > >> says is the next hop for that prefix. >> >>It doesn't make sense for Rd to bind labels to prefixes which >> >> >are more > > >>specific than the one in the routing table, as the label >> >> >imposition > > >>procedure will never make use of such labels. >> >>I don't think we want to allow LDP to put prefixes in the routing >> >> >table, or > > >>else we'd have to treat it as a second routing algorithm and that >> >> >would > > >>raise all kinds of issues. >> >> >[Bruno D:] Such procedure would not change the behavior of the IGP and >LDP. >LDP would definitely not act as a routing protocol and all routing >decisions (next-hop selection, recheability) would still rely on the > >IGP. LDP would continue advertising labels for FECs and would entirely >rely on the RIB for setting up LSPs along the IP route. > >However, as you very correctly pointed out, we would allow LDP to >"de-aggregate" the FIB and this may raise some issue. However, what is > >the difference, from the FIB point of view, between one /30 pointing to >Rd and four /32 pointing to Rd? I believe some FIB implementation >already represent a /30 as four /32. > >Besides, if populating the FTN with specific FEC is found to be an > >issue, we can only populate the ILM on all P routers. For PE/ingress >router, all we really need is BGP to be aware of these LSPs and be able >to use them to reach the BGP Next Hops. > > > >>It is possible though to imagine a different imposition procedure: >> >>- get the IP destination address, A >> >>- find the prefix, P, in the routing table which is the best match >> >> >(longest > > >> match) for that destination address >> >>- get the next hop, N, for P, as specified by routing >> >>- if N has distributed any label bindings for prefixes which are >> >> >longer than > > >> P but begin with the same sequence of bits as P, and if any of >> >> >these, say > > >> Q, is a better match for A than P, then use the label which N >> >> >assigned to > > >> Q. >> >>This is a complicated procedure, though. You can't just match A >> >> >against Q, > > >>because there might be some prefix R in the routing table, with a >> >> >different > > >>next hop, which is a better match for A than P is, but not as good a >> >> >match > > >>as Q. The above imposition procedure says that the next hop for the >> >> >packet > > >>is determined by the route to R not by the route to P (or Q). >> >> >It's a > > >>complex matter to keep the forwarding tables in proper shape, >> >> >given that > > >>prefixes like Q can come and go asynchronously. >> >> >[Bruno D:] I don't think there is a need to change the imposition >procedure at all. The modification of the label mapping procedure seems >enough. However, as pointing out by Dutta, an additional effort is > >needed to sync LDP with the RIB because as you said, more specific >prefixes can come and go. > > > > >>There are other complications as well. For example, what do you do >> >> >if you > > >>get a packet which is labeled for Q, but the next hop has changed >> >> >and the > > >>new next hop has not distributed a label for Q? >> >>I suppose we could figure all this out if there were an actual problem >> >> >which > > >>didn't have a better solution. >> >> >> >> >> >> >> >>_______________________________________________ >>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 > > > > > > -- > 101 Billerica Ave, > N.Billerica MA -01862 --------------070002010802000104030700 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Let me answer just the first part of this and let the rest take care of itself... :-)

LSPs are [terminated] at aggregation boundaries.  This may not be desirable in case of
an all-MPLS network.

To some extent, every box needs to "make up its mind" whether it is a router or a switch.
It is important in interoperating between boxes that they are each self-consistent.

The aggregator router could decide not to aggregate routing information.  That way, it can
distribute more specific labels and not worry about inconsistencies between the routes it
has advertised and the labels it distributes.

However, there are reasons why routers aggregate routing information, and I think it may
be difficult to justify why those reasons would not apply equally well to label distribution.

It may very well be the case that routing aggregation is not completely justified in specific
deployment scenarios. In that case, perhaps it would simply be better to "turn off" route
aggregation.

--
Eric

Raveendra Torvi wrote:
Eric,
According to your solution  LSPs are broken at the aggregation boundary or IGP area boundary, which may not be desirable in case of all-MPLS network. If main goal is to carry transit traffic by the way of LDP-MPLS switching , In case of all-MPLS networks an operator would like to inject only LDP-FECs in other areas (hence achieve the scalability) or avoid summarization LDP-FECs at IGP area boundary .. Please help me understand.
Ravi.


On 4/13/06, Eric W Gray <ewgray2k@netscape.net> wrote:
Bruno,

    No, if anything specific had to be said, it would be that Ru MUST NOT advertise a more
specific FEC to an upstream peer (Ruu in this case) than it has advertised in routing.

    I cannot speak - obviously - for every implementation out there, but here's how I believe
they _should_ work when dealing with an ABR (or other sumarization point):

    o   The ABR-LSR advertises summarized routes into an adjacent Area.
    o   The ABR-LSR distributes labels corresponding to those routes to LDP
          peers adjacent to it in that same Area.
    o   The ABR-LSR is then the egress for the corresponding LSPs,  in those
          cases where it has downstream routing entries corresponding to more
          specific routes.
    o   The ABR-LSR MAY - at that point - inject arriving packets on downstream
          LSPs - after it performs a routing look-up and discovers an FTN (thus
          determing an appropriate label and outgoing interface).

    As I mentioned to Pranjal, this is defined this way for scalability reasons.  It is not the
intention of MPLS generally to eliminate the need for routing capability in the network at
a cost of introducing unscalably large numbers of label distributions throughout the same
network.

    Just as an  opinion, a device that is incapable of making this kind of routing decision,
has no business being in a position to summarize routes.

--
Eric


DECRAENE Bruno RD-CORE-ISS wrote:
Eric,

Thanks for your comments.

Additional discussions inlined.

Regards,
Bruno

  
-----Original Message-----
...[SNIP]...
<>presumably the only thing at issue is Ru should label an IP packet that it receives. 
[Bruno D:] A subsequent issue, is that to continue the LSP further
upstream, Ru should allocate a new label and advertise the specific FEC
upstream to Ruu.

  
What will happen is that  the IP packet gets sent unlabeled to Rd
which then labels it according to the specific route which is the best
    
match
  
to the packet's IP destination address.
    
[Bruno D:] That is indeed the current behavior but the problem is that
Rd may not be able to forward the IP packet (eg Ru is a VPN PE and Rd is
a P). And this may not be an IP packet BTW.
 
  
The label imposition procedure here is:

- get the IP destination address
- find  the prefix  in the routing  table which  is the best  match
    
(longest
  
  match) for that destination address
- use the label  which was assigned to that prefix by  the LSR which
    
routing
  
  says is the next hop for that prefix.

It  doesn't make sense  for Rd  to bind  labels to  prefixes which
    
are more
  
specific  than  the  one in  the  routing  table,  as the  label
    
imposition
  
procedure will never make use of such labels.

I don't think we want to allow  LDP to put prefixes in the routing
    
table, or
  
else we'd  have to  treat it as  a second  routing algorithm and  that
    
would
  
raise all kinds of issues.
    
[Bruno D:] Such procedure would not change the behavior of the IGP and
LDP.
LDP would definitely not act as a routing protocol and all routing
decisions (next-hop selection, recheability) would still rely on the

IGP. LDP would continue advertising labels for FECs and would entirely
rely on the RIB for setting up LSPs along the IP route.

However, as you very correctly pointed out, we would allow LDP to
"de-aggregate" the FIB and this may raise some issue. However, what is

the difference, from the FIB point of view, between one /30 pointing to
Rd and four /32 pointing to Rd? I believe some FIB implementation
already represent a /30 as four /32.

Besides, if populating the FTN with specific FEC is found to be an

issue, we can only populate the ILM on all P routers. For PE/ingress
router, all we really need is BGP to be aware of these LSPs and be able
to use them to reach the BGP Next Hops.

  
It is possible though to imagine a different imposition procedure:

- get the IP destination address, A

- find the prefix, P, in the routing table which is the best match
    
(longest
  
  match) for that destination address

- get the next hop, N, for P, as specified by routing

- if N has distributed any label bindings for prefixes which are
    
longer than
  
  P but begin with the same sequence of  bits as P, and if any of
    
these, say
  
  Q, is a better match for A than  P, then use the label which N
    
assigned to
  
  Q.

This is a complicated procedure, though.   You can't just match A
    
against Q,
  
because there might be some prefix  R in the routing table, with a
    
different
  
next hop, which is  a better match for A than P is, but  not as good a
    
match
  
as Q.  The above imposition procedure  says that the next hop for the
    
packet
  
is determined  by the  route to  R not  by the route  to P  (or Q).
    
It's a
  
complex matter  to keep  the forwarding tables  in proper shape,
    
given that
  
prefixes like Q can come and go asynchronously.
    
[Bruno D:] I don't think there is a need to change the imposition
procedure at all. The modification of the label mapping procedure seems
enough. However, as pointing out by Dutta, an additional effort is

needed to sync LDP with the RIB because as you said, more specific
prefixes can come and go.

 
  
There are other  complications as well.  For example, what do  you do
    
if you
  
get a packet  which is labeled for Q,  but the next hop has  changed
    
and the
  
new next hop has not distributed a label for Q?

I suppose we could figure all this out if there were an actual problem
    
which
  
didn't have a better solution.







_______________________________________________
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





--
101 Billerica Ave,
N.Billerica MA -01862
--------------070002010802000104030700-- --===============1472848090== 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 --===============1472848090==-- From mpls-bounces@lists.ietf.org Thu Apr 13 12:12:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU4Os-0003sw-4K; Thu, 13 Apr 2006 12:10:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU4Oq-0003sr-61 for mpls@ietf.org; Thu, 13 Apr 2006 12:10:28 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU4Op-0001cu-PZ for mpls@ietf.org; Thu, 13 Apr 2006 12:10:28 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 18:10:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] One LDP Implementation specific question ofreceive labelmapping for prefix FECs Date: Thu, 13 Apr 2006 18:10:00 +0200 Message-ID: <5A0FF108221C7C4E85738678804B567C032CD968@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] One LDP Implementation specific question ofreceive labelmapping for prefix FECs Thread-Index: AcZfBVLJIM28jcDqQouwk2EAqQgxLQAAFxWgAAIWa+A= From: "DECRAENE Bruno RD-CORE-ISS" To: "David Allan" X-OriginalArrivalTime: 13 Apr 2006 16:10:02.0555 (UTC) FILETIME=[B878D8B0:01C65F14] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: mpls@ietf.org, ewgray@GraIyMage.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org David, Thanks for the feedback. I'll need to re-read LSP Ping to check if there is a potential interaction. Could you please be more specific on the LSP Ping section that could be impacted? However, please note that the LDP FEC is not changed on its way from egress to ingress. In particular, the LDP FEC is not aggregated and all LSRs on the way know the exact same FEC. Cheers, Bruno > -----Original Message----- > From: David Allan [mailto:dallan@nortel.com] > Sent: Thursday, April 13, 2006 4:29 PM > To: ewgray@GraIyMage.com; DECRAENE Bruno RD-CORE-ISS; pdutta@riverstonenet.com > Cc: mpls@ietf.org > Subject: RE: [mpls] One LDP Implementation specific question ofreceive labelmapping for prefix FECs >=20 > FYI >=20 > It does go further, re-writing FEC stack processing for LSP ping to permit interpretation and > matching of more specific to less specific prefixes and figuring out whether that was actually > permissable in the local context (a.k.a. more specific prefix did not exist at the terminating LSR) > could get truly ugly... >=20 > cheers > Dave >=20 > > -----Original Message----- > > From: Eric W Gray [mailto:ewgray2k@netscape.net] > > Sent: Thursday, April 13, 2006 10:17 AM > > To: DECRAENE Bruno RD-CORE-ISS; pdutta@riverstonenet.com > > Cc: mpls@ietf.org > > Subject: Re: [mpls] One LDP Implementation specific question > > ofreceive labelmapping for prefix FECs > > > > > > Bruno/Pranjal, > > > > One thing I would like to make perfectly clear in this > > discussion is > > that - if either or > > both of you would like to write an ID that proposes changing or > > extending LDP to do > > what you suggest, you should do so. The suggestions you make may be > > well received > > by participants in the MPLS working group. > > > > However, you should not view this as something to > > "correct" in the > > current LDP > > specification. The point of the current LDP specification work is to > > document what is > > being done in current interoperable implementations, now. > > > > I believe the point has been sufficiently well made by > > now that the > > text - as is - > > represents current implementation better than the changes > > you've implied > > or explicitly > > suggested should be made with respect to the exact match > > requirement in > > handling an > > arriving label distribution. > > > > -- > > Eric > > > > > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Apr 13 14:06:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU6AK-0000Fp-Qh; Thu, 13 Apr 2006 14:03:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU6AK-0000Fk-7I for mpls@ietf.org; Thu, 13 Apr 2006 14:03:36 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU6AK-0005Tg-04 for mpls@ietf.org; Thu, 13 Apr 2006 14:03:36 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 13 Apr 2006 14:03:36 -0400 X-IronPort-AV: i="4.04,118,1144036800"; d="scan'208"; a="86393850:sNHT30114188" Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3DI3ZvF027332; Thu, 13 Apr 2006 14:03:35 -0400 (EDT) Message-Id: <200604131803.k3DI3ZvF027332@rtp-core-2.cisco.com> To: "DECRAENE Bruno RD-CORE-ISS" Subject: Re: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs In-reply-to: Your message of Thu, 13 Apr 2006 10:27:48 +0200. <5A0FF108221C7C4E85738678804B567C032CD625@ftrdmel3.rd.francetelecom.fr> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 13 Apr 2006 14:03:35 -0400 From: Eric Rosen X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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: , Errors-To: mpls-bounces@lists.ietf.org Bruno> A subsequent issue, is that to continue the LSP further upstream, Ru Bruno> should allocate a new label and advertise the specific FEC upstream Bruno> to Ruu. How does Ru know whether Ruu wants or needs this? Bruno> what is the difference, from the FIB point of view, between one /30 Bruno> pointing to Rd and four /32 pointing to Rd? I believe some FIB Bruno> implementation already represent a /30 as four /32 Do they also represent a /8 as 16,777,216 /32s? ;-) I'm not sure we want to require such an implementation. The issue is not the size of the FIB, it's the complexity of the procedures used to maintain the FIB. Bruno> if populating the FTN with specific FEC is found to be an issue, we Bruno> can only populate the ILM on all P routers. I don't think the issues are any different. Bruno> For PE/ingress router, all we really need is BGP to be aware of these Bruno> LSPs and be able to use them to reach the BGP Next Hops I don't think that's a simplification. But if that's what you want, why not use RSVP-TE to create a tunnel to each potential BGP next hop? The underlying issue in the L3VPN application is, I think, the following. The bottom label of an L3VPN data packet has to correspond to a VPN-IP route. The label above that has to correspond to the router which is the BGP next hop for that VPN-IP route, i.e., it has to correspond to a /32. Typically the IGP is made to carry /32 routes for anything that could be the BGP next hop of a VPN-IP route. The worry is that ultimately there may be so many of these that the IGP does not scale well enough to put all these /32s in the FIBs of the P routers. In that case, I don't think the solution is to find some other, more complex way to put all the /32s in the FIBs of the P routers. I don't think that having a more complicated way to handle the same amount of information is going to get us very far. What we really want is a hierarchical solution, in which a third label is used to get the packets to a point where the second label is known. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Apr 14 01:46:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUH64-0007Xz-Pc; Fri, 14 Apr 2006 01:43:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUH63-0007Xt-E1 for mpls@ietf.org; Fri, 14 Apr 2006 01:43:55 -0400 Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUH60-0003x7-UU for mpls@ietf.org; Fri, 14 Apr 2006 01:43:53 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id WAA26548; Thu, 13 Apr 2006 22:43:43 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [mpls] One LDP Implementation specific question ofreceive labelmapping for prefix FECs Date: Fri, 14 Apr 2006 11:13:41 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] One LDP Implementation specific question ofreceive labelmapping for prefix FECs Thread-Index: AcZfA0sbDYs0rqcjSZaq4pDHnXkeFQAgdHog From: "Dutta, Pranjal" To: , "DECRAENE Bruno RD-CORE-ISS" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad 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="===============1821724690==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1821724690== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65F86.63160F67" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65F86.63160F67 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi Eric, Just one comment inlined. =20 Thanks, Pranjal =20 ________________________________ From: Eric W Gray [mailto:ewgray2k@netscape.net]=20 Sent: Thursday, 13 April, 2006 7:33 PM To: DECRAENE Bruno RD-CORE-ISS Cc: mpls@ietf.org Subject: Re: [mpls] One LDP Implementation specific question ofreceive labelmapping for prefix FECs =20 Bruno, No, if anything specific had to be said, it would be that Ru MUST NOT advertise a more specific FEC to an upstream peer (Ruu in this case) than it has advertised in routing. I cannot speak - obviously - for every implementation out there, but here's how I believe they _should_ work when dealing with an ABR (or other sumarization point): o The ABR-LSR advertises summarized routes into an adjacent Area. o The ABR-LSR distributes labels corresponding to those routes to LDP peers adjacent to it in that same Area. o The ABR-LSR is then the egress for the corresponding LSPs, in those=20 cases where it has downstream routing entries corresponding to more=20 specific routes. [Pranjal] This is the very critical point. In this case Rd has more specific entries, but it has decided that its not the egress for those=20 FECs (specific entries), rather the egress for the summary FECs (Prefixes) that it had advertised to Ru, If that is so than LDP has to be more tightly coupled with Routing (specific IGP and needs to track which Route got summarized across boundaries or so),right? o The ABR-LSR MAY - at that point - inject arriving packets on downstream=20 LSPs - after it performs a routing look-up and discovers an FTN (thus determing an appropriate label and outgoing interface). As I mentioned to Pranjal, this is defined this way for scalability reasons. It is not the=20 intention of MPLS generally to eliminate the need for routing capability in the network at a cost of introducing unscalably large numbers of label distributions throughout the same network. Just as an opinion, a device that is incapable of making this kind of routing decision, has no business being in a position to summarize routes. -- Eric =20 =20 ------_=_NextPart_001_01C65F86.63160F67 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi = Eric,

      =          Just one comment inlined.

 

Thanks,

=

Pranjal

=

 

From: Eric W Gray [mailto:ewgray2k@netscape.net]
Sent: Thursday, 13 April, = 2006 7:33 PM
To: DECRAENE Bruno = RD-CORE-ISS
Cc: mpls@ietf.org
Subject: Re: [mpls] One = LDP Implementation specific question ofreceive labelmapping for prefix = FECs

 

Bruno,

    No, if anything specific had to be said, it would be = that Ru MUST NOT advertise a more
specific FEC to an upstream peer (Ruu in this case) than it has = advertised in routing.

    I cannot speak - obviously - for every implementation = out there, but here's how I believe
they _should_ work when dealing with an ABR (or other sumarization = point):

    o   The ABR-LSR advertises summarized = routes into an adjacent Area.
    o   The ABR-LSR distributes labels = corresponding to those routes to LDP
          peers adjacent to it in = that same Area.
    o   The ABR-LSR is then the egress for the corresponding LSPs,  in those
          cases where it has = downstream routing entries corresponding to more
          specific = routes.

[Pranjal] This is the very critical = point. In this case Rd has more specific entries, but it has decided that its = not the egress for those

FECs (specific entries), rather the = egress for the summary FECs (Prefixes) that it had advertised to Ru, If that is = so than LDP has to

be more tightly coupled with = Routing (specific IGP and needs to track which Route got summarized across = boundaries or so),right?


    o   The ABR-LSR MAY - at that point - = inject arriving packets on downstream
          LSPs - after it = performs a routing look-up and discovers an FTN (thus
          determing an appropriate = label and outgoing interface).

    As I mentioned to Pranjal, this is defined this way = for scalability reasons.  It is not the
intention of MPLS generally to eliminate the need for routing capability = in the network at
a cost of introducing unscalably large numbers of label distributions throughout the same
network.

    Just as an  opinion, a device that is incapable = of making this kind of routing decision,
has no business being in a position to summarize routes.

--
Eric

 

= 
 
------_=_NextPart_001_01C65F86.63160F67-- --===============1821724690== 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 --===============1821724690==-- From mpls-bounces@lists.ietf.org Fri Apr 14 01:50:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUHAJ-0001Kj-5o; Fri, 14 Apr 2006 01:48:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUHAI-0001Ke-1Q for mpls@ietf.org; Fri, 14 Apr 2006 01:48:18 -0400 Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUHAH-00042c-Ig for mpls@ietf.org; Fri, 14 Apr 2006 01:48:18 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id WAA26835; Thu, 13 Apr 2006 22:48:11 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [mpls] One LDP Implementation specific question of receivelabelmapping for prefix FECs Date: Fri, 14 Apr 2006 11:18:10 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] One LDP Implementation specific question of receivelabelmapping for prefix FECs Thread-Index: AcZfEUX20VfTi2NrQ/iMTheDfCxI8AAdHK9g From: "Dutta, Pranjal" To: , "Raveendra Torvi" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 Cc: DECRAENE Bruno RD-CORE-ISS , 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="===============0356612328==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0356612328== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65F87.0323E3F5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65F87.0323E3F5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Earlier mail got bounced..resending again... =20 Hi Eric, This answers well to the concern. It would depend whether we would like to have an all MPLS network spanning via LDP or not. It is well said that aggregation can be turned off or on based on the whether we would like to have an inter-area LSP or not. At this point I would=20 like to go by that at Rd, LDP is unaware of whether the prefix entries found in its route table for downstream has been summarized to Ru. As David said=20 it has a side effect with LSP-Ping. =20 Regards, Pranjal =20 ________________________________ From: Eric W Gray [mailto:ewgray2k@netscape.net]=20 Sent: Thursday, 13 April, 2006 9:13 PM To: Raveendra Torvi Cc: DECRAENE Bruno RD-CORE-ISS; mpls@ietf.org Subject: Re: [mpls] One LDP Implementation specific question of receivelabelmapping for prefix FECs =20 Let me answer just the first part of this and let the rest take care of itself... :-) LSPs are [terminated] at aggregation boundaries. This may not be desirable in case of an all-MPLS network. To some extent, every box needs to "make up its mind" whether it is a router or a switch. It is important in interoperating between boxes that they are each self-consistent. The aggregator router could decide not to aggregate routing information. That way, it can distribute more specific labels and not worry about inconsistencies between the routes it has advertised and the labels it distributes. However, there are reasons why routers aggregate routing information, and I think it may be difficult to justify why those reasons would not apply equally well to label distribution. It may very well be the case that routing aggregation is not completely justified in specific deployment scenarios. In that case, perhaps it would simply be better to "turn off" route aggregation. -- Eric =20 ------_=_NextPart_001_01C65F87.0323E3F5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Earlier mail got bounced..resending = again…

 

Hi = Eric,

      =            This answers well to the concern. It would depend whether we would like = to have an all MPLS network spanning via LDP or = not.

It is well said that aggregation = can be turned off or on based on the whether we would like to have an = inter-area LSP or not. At this point I would

like to go by that at Rd, LDP is = unaware of whether the prefix entries found in its route table for downstream = has been summarized to Ru. As David said

it has a side effect with = LSP-Ping.

 

Regards,

Pranjal

=

 

From: Eric W Gray [mailto:ewgray2k@netscape.net]
Sent: Thursday, 13 April, = 2006 9:13 PM
To: Raveendra Torvi
Cc: DECRAENE Bruno = RD-CORE-ISS; mpls@ietf.org
Subject: Re: [mpls] One = LDP Implementation specific question of receivelabelmapping for prefix = FECs

 

Let me answer just the first part of this and = let the rest take care of itself... :-)

LSPs = are [terminated] at aggregation boundaries.  This may not be desirable = in case of
an all-MPLS network.

To some extent, every box needs to "make up its mind" whether = it is a router or a switch.
It is important in interoperating between boxes that they are each self-consistent.

The aggregator router could decide not to aggregate routing = information.  That way, it can
distribute more specific labels and not worry about inconsistencies = between the routes it
has advertised and the labels it distributes.

However, there are reasons why routers aggregate routing information, = and I think it may
be difficult to justify why those reasons would not apply equally well = to label distribution.

It may very well be the case that routing aggregation is not completely justified in specific
deployment scenarios. In that case, perhaps it would simply be better to "turn off" route
aggregation.

--
Eric

 

------_=_NextPart_001_01C65F87.0323E3F5-- --===============0356612328== 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 --===============0356612328==-- From mpls-bounces@lists.ietf.org Fri Apr 14 05:55:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUKyM-0002eO-2K; Fri, 14 Apr 2006 05:52:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUKyL-0002eJ-0O for mpls@ietf.org; Fri, 14 Apr 2006 05:52:13 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUKyK-0003Mo-Ia for mpls@ietf.org; Fri, 14 Apr 2006 05:52:12 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Apr 2006 11:52:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs Date: Fri, 14 Apr 2006 11:52:03 +0200 Message-ID: <5A0FF108221C7C4E85738678804B567C032CDB7A@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs Thread-Index: AcZfJJZcQMWAxJxWQq6s5TRDH8wRigAeRtnw From: "DECRAENE Bruno RD-CORE-ISS" To: X-OriginalArrivalTime: 14 Apr 2006 09:52:05.0222 (UTC) FILETIME=[16243060:01C65FA9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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: , Errors-To: mpls-bounces@lists.ietf.org > Bruno> A subsequent issue, is that to continue the LSP further upstream, Ru > Bruno> should allocate a new label and advertise the specific FEC upstream > Bruno> to Ruu. >=20 > How does Ru know whether Ruu wants or needs this? [Bruno D:] In Downstream Unsolicited label advertisement mode, Ru does not know what Ruu wants or needs. Ru always propagates the FEC upstream and Ruu uses it if needed. =20 > Bruno> what is the difference, from the FIB point of view, between one /30 > Bruno> pointing to Rd and four /32 pointing to Rd? I believe some FIB > Bruno> implementation already represent a /30 as four /32 >=20 > Do they also represent a /8 as 16,777,216 /32s? ;-) I'm not sure we want to > require such an implementation. [Bruno D:] No they don't ;-) They can even handle a /8 and a more specific /32 without de-aggregating 16,777,216 /32s ! However, regarding our proposition, there is no change compared to using RFC 3036 and performing route leaking on ABR. In both cases, in the FIB, you have an aggregated prefix and more specific ones. =20 > The issue is not the size of the FIB, it's the complexity of the procedures > used to maintain the FIB. [Bruno D:] Agreed. And the point of the discussion is to balance the additional LDP implementation cost with the IGP protocol gain of not carrying the specific prefixes. Regarding the implementation cost, I suppose this may be implementation dependant and I would welcome any information from people implementing /having implemented LDP (either privately or publicly on the mailing list). Regarding the protocol gain, basically, instead of advertising the specific prefixes once in the IGP and once in the LDP, we would only advertise it once (in LDP, and LDP seems the good choice because MPLS does need the specific FEC whereas IP can handle and benefit from aggregation.). So the gain is globally a factor 2 in the control plane (...with no gain for LDP and all the gain for the IGP, which makes it more difficult to defend on the MPLS side ;-) ). =20 > Bruno> if populating the FTN with specific FEC is found to be an issue, we > Bruno> can only populate the ILM on all P routers. >=20 > I don't think the issues are any different. =20 > Bruno> For PE/ingress router, all we really need is BGP to be aware of these > Bruno> LSPs and be able to use them to reach the BGP Next Hops >=20 > I don't think that's a simplification. But if that's what you want, why not > use RSVP-TE to create a tunnel to each potential BGP next hop? [Bruno D:] LDP creates multipoint to point LSP so scales in o(N). RSVP-TE creates point to point LSP so scales in o(N^2). But the point now is not whether we should have one or two protocols to set-up LSPs. We have both and I believe we could equally extend both protocols to be IGP area friendly. > The underlying issue in the L3VPN application is, I think, the following. > The bottom label of an L3VPN data packet has to correspond to a VPN-IP > route. The label above that has to correspond to the router which is the > BGP next hop for that VPN-IP route, i.e., it has to correspond to a /32. [Bruno D:] Agreed. That is the case with our proposition: the /32 FEC is advertised all the way from egress to ingress, and the /32 FEC exactly matches the BGP next-hop which advertised the VPN route. > Typically the IGP is made to carry /32 routes for anything that could be the > BGP next hop of a VPN-IP route. The worry is that ultimately there may be > so many of these that the IGP does not scale well enough to put all these > /32s in the FIBs of the P routers. In that case, I don't think the solution > is to find some other, more complex way to put all the /32s in the FIBs of > the P routers. I don't think that having a more complicated way to handle > the same amount of information is going to get us very far. =20 [Bruno D:] Indeed, if the limiting factor is the size of the FIB, our proposition does not solve this. Otherwise, our proposition improves the control plane scalability with -from the LDP specification point a view- a very limited modification.=20 > What we really want is a hierarchical solution [Bruno D:] I suppose it depends who you mean by "we" ;-) > in which a third label is used to get the > packets to a point where the second label is known. [Bruno D:] The hierarchical solution has its own pro & con. FIB scaling (especially on the P routers) is indeed a key advantage. One disadvantage is that if some kind of a LDP/IP FRR solution is implemented, the intermediate point is difficult to fast protect. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Apr 14 12:53:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FURWP-0006QH-A7; Fri, 14 Apr 2006 12:51:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FURWO-0006Ng-JM for mpls@ietf.org; Fri, 14 Apr 2006 12:51:48 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FURWO-0008BN-Cg for mpls@ietf.org; Fri, 14 Apr 2006 12:51:48 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 14 Apr 2006 09:51:46 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,121,1144047600"; d="scan'208"; a="25921415:sNHT22406304" 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 k3EGpjTL002085; Fri, 14 Apr 2006 12:51:45 -0400 (EDT) Message-Id: <200604141651.k3EGpjTL002085@rtp-core-1.cisco.com> To: "DECRAENE Bruno RD-CORE-ISS" Subject: Re: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs In-reply-to: Your message of Fri, 14 Apr 2006 11:52:03 +0200. <5A0FF108221C7C4E85738678804B567C032CDB7A@ftrdmel3.rd.francetelecom.fr> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 14 Apr 2006 12:51:45 -0400 From: Eric Rosen 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 Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org > In Downstream Unsolicited label advertisement mode, Ru does > not know what Ruu wants or needs. Ru always propagates the FEC upstream > and Ruu uses it if needed. So once some node decides to do this "LDP de-summarization", there's no way to stop it until you reach the border of the MPLS domain? I think we'd probably end up with a bunch of configuration knobs controlling LDP desummarization, similar to the knobs controlling IGP summarization. > there is no change compared to using RFC 3036 and performing route leaking > on ABR. In both cases, in the FIB, you have an aggregated prefix and more > specific ones. I didn't say that your proposal adds more prefixes to the FIB than it would have if the the /32s were carried by OSPF. I said that the management of the forwarding table is made more complicated, because we now have entries which are jointly managed by two different protocols which have a complex relationship with each other. > instead of advertising the specific prefixes once in the IGP and once in > the LDP, we would only advertise it once I don't think this is a meaningful comparison. LDP does not currently advertise prefixes, it advertises label bindings. In your proposal, new functionality is added so that LDP does advertise prefixes. Thus the number of "prefix advertisements" stays the same. You're merely shifting some of the prefix advertisement burden from one protocol to the other. And the work of managing those prefixes in the forwarding table is more complicated. All that really gets saved is the work required to parse the OSPF messages. I guess my problem is that I see the additional complexity, but I don't see the data showing that, as a result of adding this complexity, we gain a big improvement in the number of /32s to which we can assign labels. I also don't see that this is yields a better set of tradeoffs than a hierarchical soltuion. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Apr 14 14:18:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSqE-0004nZ-9f; Fri, 14 Apr 2006 14:16:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSqD-0004nU-D5 for mpls@ietf.org; Fri, 14 Apr 2006 14:16:21 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUSqD-0002vo-0t for mpls@ietf.org; Fri, 14 Apr 2006 14:16:21 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Apr 2006 20:16:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs Date: Fri, 14 Apr 2006 20:16:16 +0200 Message-ID: <5A0FF108221C7C4E85738678804B567C032CDE41@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs Thread-Index: AcZf47lewg3ATk9MQh2wXPCM4fmaIgAA+iIw From: "DECRAENE Bruno RD-CORE-ISS" To: X-OriginalArrivalTime: 14 Apr 2006 18:16:17.0884 (UTC) FILETIME=[862211C0:01C65FEF] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org > > In Downstream Unsolicited label advertisement mode, Ru does > > not know what Ruu wants or needs. Ru always propagates the FEC upstream > > and Ruu uses it if needed. >=20 > So once some node decides to do this "LDP de-summarization", there's no way > to stop it until you reach the border of the MPLS domain? I think we'd > probably end up with a bunch of configuration knobs controlling LDP > desummarization, similar to the knobs controlling IGP summarization. [Bruno D:] In most implementation, there is already the ability to use route-map to control the advertisement of LDP FEC. We are using them in our networks to restrict the advertisements. Besides, the proposed modification would be optional. If you don't turn it on, you still have the current behavior (FEC gets stop at area boundaries). =20 > > instead of advertising the specific prefixes once in the IGP and once in > > the LDP, we would only advertise it once >=20 > I don't think this is a meaningful comparison. LDP does not currently > advertise prefixes, it advertises label bindings. In your proposal, new > functionality is added so that LDP does advertise prefixes. Thus the number > of "prefix advertisements" stays the same. You're merely shifting some of > the prefix advertisement burden from one protocol to the other. And the > work of managing those prefixes in the forwarding table is more > complicated. All that really gets saved is the work required to parse the > OSPF messages. [Bruno D:] OK, I should have use exact terms. My mistake. As an example, In one hand you advertise 1000 specific prefixes in the IGP and 1000 FEC & labels in LDP. On the other hand you advertise 1 to 10 aggregated prefixes in the IGP and 1000 FEC & labels in LDP. There is definitely a gain for the IGP (especially for the ABRs which need to redistribute all the prefixes in a single LSA/LSP). But there is no gain plus an additional complexity for LDP. > I guess my problem is that I see the additional complexity, but I don't see > the data showing that, as a result of adding this complexity, we gain a big > improvement in the number of /32s to which we can assign labels. =20 Thanks for raising this additional complexity which is indeed not described in the current version of the draft.=20 I agree that this is difficult to evaluate the overall scalability gain without measurement on a prototype or by simulations. Two others points can be taken into consideration and are pertinent for our deployment: - in some areas, especially in the edge/backhaul, not all router may need MPLS. For them the gain is easy to measure. - in some areas, the network may already be running and the point is to add inter-area MPLS for additional services. Without the proposed modification, the impact on the IGP (and potentially to weaker equipment) is certain and significant. Not to mention the need to change the IP routing policy (currently, aggregation is performed on ABR) > I also don't see that this is yields a better set of tradeoffs than a hierarchical > soltuion. [Bruno D:] I would say that this yields to a different set of tradeoffs, which may better fit in some deployments. Regards, Bruno _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Apr 17 17:02:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVapg-0002lq-1k; Mon, 17 Apr 2006 17:00:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU6Ak-0000HN-8I for mpls@ietf.org; Thu, 13 Apr 2006 14:04:02 -0400 Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU6Aj-0005UI-4J for mpls@ietf.org; Thu, 13 Apr 2006 14:04:02 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id LAA17202; Thu, 13 Apr 2006 11:03:53 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [mpls] One LDP Implementation specific question ofreceive labelmapping for prefix FECs Date: Thu, 13 Apr 2006 23:33:51 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] One LDP Implementation specific question ofreceive labelmapping for prefix FECs Thread-Index: AcZfA0sbDYs0rqcjSZaq4pDHnXkeFQAH1dJg From: "Dutta, Pranjal" To: , "DECRAENE Bruno RD-CORE-ISS" X-Spam-Score: 0.0 (/) X-Scan-Signature: d3555fd4ff2ff34d62a586467d12846b X-Mailman-Approved-At: Mon, 17 Apr 2006 17:00:24 -0400 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0772916114==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0772916114== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65F24.9EF994D5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65F24.9EF994D5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eric, Just one comment inlined. =20 Thanks, Pranjal =20 ________________________________ From: Eric W Gray [mailto:ewgray2k@netscape.net]=20 Sent: Thursday, 13 April, 2006 7:33 PM To: DECRAENE Bruno RD-CORE-ISS Cc: mpls@ietf.org Subject: Re: [mpls] One LDP Implementation specific question ofreceive labelmapping for prefix FECs =20 Bruno, No, if anything specific had to be said, it would be that Ru MUST NOT advertise a more specific FEC to an upstream peer (Ruu in this case) than it has advertised in routing. I cannot speak - obviously - for every implementation out there, but here's how I believe they _should_ work when dealing with an ABR (or other sumarization point): o The ABR-LSR advertises summarized routes into an adjacent Area. o The ABR-LSR distributes labels corresponding to those routes to LDP peers adjacent to it in that same Area. o The ABR-LSR is then the egress for the corresponding LSPs, in those=20 cases where it has downstream routing entries corresponding to more=20 specific routes. [Pranjal] This is the very critical point. In this case Rd has more specific entries, but it has decided that its not the egress for those=20 FECs (specific entries), rather the egress for the summary FECs (Prefixes) that it had advertised to Ru, If that is so than LDP has to be more tightly coupled with Routing (specific IGP and needs to track which Route got summarized across boundaries or so),right? o The ABR-LSR MAY - at that point - inject arriving packets on downstream=20 LSPs - after it performs a routing look-up and discovers an FTN (thus determing an appropriate label and outgoing interface). As I mentioned to Pranjal, this is defined this way for scalability reasons. It is not the=20 intention of MPLS generally to eliminate the need for routing capability in the network at a cost of introducing unscalably large numbers of label distributions throughout the same network. Just as an opinion, a device that is incapable of making this kind of routing decision, has no business being in a position to summarize routes. -- Eric DECRAENE Bruno RD-CORE-ISS wrote: Eric, =20 Thanks for your comments. =20 Additional discussions inlined. =20 Regards, Bruno =20 =20 -----Original Message----- ...[SNIP]... <>presumably the only thing at issue is Ru should label an IP packet that it receives.=20 =20 [Bruno D:] A subsequent issue, is that to continue the LSP further upstream, Ru should allocate a new label and advertise the specific FEC upstream to Ruu. =20 =20 What will happen is that the IP packet gets sent unlabeled to Rd which then labels it according to the specific route which is the best =20 match =20 to the packet's IP destination address. =20 =20 [Bruno D:] That is indeed the current behavior but the problem is that Rd may not be able to forward the IP packet (eg Ru is a VPN PE and Rd is a P). And this may not be an IP packet BTW. =20 =20 The label imposition procedure here is: =20 - get the IP destination address - find the prefix in the routing table which is the best match =20 (longest =20 match) for that destination address - use the label which was assigned to that prefix by the LSR which =20 routing =20 says is the next hop for that prefix. =20 It doesn't make sense for Rd to bind labels to prefixes which =20 are more =20 specific than the one in the routing table, as the label =20 imposition =20 procedure will never make use of such labels. =20 I don't think we want to allow LDP to put prefixes in the routing =20 table, or =20 else we'd have to treat it as a second routing algorithm and that =20 would =20 raise all kinds of issues. =20 =20 [Bruno D:] Such procedure would not change the behavior of the IGP and LDP. LDP would definitely not act as a routing protocol and all routing decisions (next-hop selection, recheability) would still rely on the IGP. LDP would continue advertising labels for FECs and would entirely rely on the RIB for setting up LSPs along the IP route. =20 However, as you very correctly pointed out, we would allow LDP to "de-aggregate" the FIB and this may raise some issue. However, what is the difference, from the FIB point of view, between one /30 pointing to Rd and four /32 pointing to Rd? I believe some FIB implementation already represent a /30 as four /32. =20 Besides, if populating the FTN with specific FEC is found to be an issue, we can only populate the ILM on all P routers. For PE/ingress router, all we really need is BGP to be aware of these LSPs and be able to use them to reach the BGP Next Hops. =20 =20 It is possible though to imagine a different imposition procedure: =20 - get the IP destination address, A =20 - find the prefix, P, in the routing table which is the best match =20 (longest =20 match) for that destination address =20 - get the next hop, N, for P, as specified by routing =20 - if N has distributed any label bindings for prefixes which are =20 longer than =20 P but begin with the same sequence of bits as P, and if any of =20 these, say =20 Q, is a better match for A than P, then use the label which N =20 assigned to =20 Q. =20 This is a complicated procedure, though. You can't just match A =20 against Q, =20 because there might be some prefix R in the routing table, with a =20 different =20 next hop, which is a better match for A than P is, but not as good a =20 match =20 as Q. The above imposition procedure says that the next hop for the =20 packet =20 is determined by the route to R not by the route to P (or Q). =20 It's a =20 complex matter to keep the forwarding tables in proper shape, =20 given that =20 prefixes like Q can come and go asynchronously. =20 =20 [Bruno D:] I don't think there is a need to change the imposition procedure at all. The modification of the label mapping procedure seems enough. However, as pointing out by Dutta, an additional effort is needed to sync LDP with the RIB because as you said, more specific prefixes can come and go. =20 =20 =20 There are other complications as well. For example, what do you do =20 if you =20 get a packet which is labeled for Q, but the next hop has changed =20 and the =20 new next hop has not distributed a label for Q? =20 I suppose we could figure all this out if there were an actual problem =20 which =20 didn't have a better solution. =20 =20 =20 =20 =20 =20 =20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls =20 =20 =20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls =20 =20 =20 =20 ------_=_NextPart_001_01C65F24.9EF994D5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Eric,

      =          Just one comment = inlined.

 

Thanks,

=

Pranjal

=

 

From: Eric W Gray [mailto:ewgray2k@netscape.net]
Sent: Thursday, 13 April, = 2006 7:33 PM
To: DECRAENE Bruno = RD-CORE-ISS
Cc: mpls@ietf.org
Subject: Re: [mpls] One = LDP Implementation specific question ofreceive labelmapping for prefix = FECs

 

Bruno,

    No, if anything specific had to be said, it would be = that Ru MUST NOT advertise a more
specific FEC to an upstream peer (Ruu in this case) than it has = advertised in routing.

    I cannot speak - obviously - for every implementation = out there, but here's how I believe
they _should_ work when dealing with an ABR (or other sumarization = point):

    o   The ABR-LSR advertises summarized = routes into an adjacent Area.
    o   The ABR-LSR distributes labels = corresponding to those routes to LDP
          peers adjacent to it in = that same Area.
    o   The ABR-LSR is then the egress for the corresponding LSPs,  in those
          cases where it has = downstream routing entries corresponding to more
          specific = routes.

[Pranjal] This is the very critical = point. In this case Rd has more specific entries, but it has decided that its = not the egress for those

FECs (specific entries), rather the = egress for the summary FECs (Prefixes) that it had advertised to Ru, If that is = so than LDP has to

be more tightly coupled with = Routing (specific IGP and needs to track which Route got summarized across = boundaries or so),right?


    o   The ABR-LSR MAY - at that point - = inject arriving packets on downstream
          LSPs - after it = performs a routing look-up and discovers an FTN (thus
          determing an appropriate = label and outgoing interface).

    As I mentioned to Pranjal, this is defined this way = for scalability reasons.  It is not the
intention of MPLS generally to eliminate the need for routing capability = in the network at
a cost of introducing unscalably large numbers of label distributions throughout the same
network.

    Just as an  opinion, a device that is incapable = of making this kind of routing decision,
has no business being in a position to summarize routes.

--
Eric

DECRAENE Bruno RD-CORE-ISS wrote:

Eric,
 
Thanks for your =
comments.
 
Additional discussions =
inlined.
 
Regards,
Bruno
 
  
-----Original =
Message-----
...[SNIP]...

<>presumably the only thing at issue is = Ru should label an IP packet that it receives. = 

 
[Bruno D:] A subsequent issue, is that to =
continue the LSP further
upstream, Ru should allocate a new label and =
advertise the specific FEC
upstream to =
Ruu.
 
  
What will happen is that  the IP packet =
gets sent unlabeled to Rd
which then labels it according to the =
specific route which is the =
best
    =

match
  
to the packet's IP destination =
address.
    =

 
[Bruno D:] That is indeed the current =
behavior but the problem is =
that
Rd may not be able to forward the IP packet =
(eg Ru is a VPN PE and Rd is
a P). And this may not be an IP packet =
BTW.
 
  
The label imposition procedure here =
is:
 
- get the IP destination =
address
- find  the prefix  in the =
routing  table which  is the best  =
match
    =

(longest
  
  match) for that destination =
address
- use the label  which was assigned to =
that prefix by  the LSR =
which
    =

routing
  
  says is the next hop for that =
prefix.
 
It  doesn't make sense  for =
Rd  to bind  labels to  prefixes =
which
    =

are =
more
  
specific  than  the  one =
in  the  routing  table,  as the  =
label
    =

imposition
=
  
procedure will never make use of such =
labels.
 
I don't think we want to allow  LDP to =
put prefixes in the routing
    =

table, =
or
  
else we'd  have to  treat it =
as  a second  routing algorithm and  =
that
    =

would
  
raise all kinds of =
issues.
    =

 
[Bruno D:] Such procedure would not change =
the behavior of the IGP and
LDP.
LDP would definitely not act as a routing =
protocol and all routing
decisions (next-hop selection, recheability) =
would still rely on the
IGP. LDP would continue advertising labels =
for FECs and would entirely
rely on the RIB for setting up LSPs along the =
IP route.
 
However, as you very correctly pointed out, =
we would allow LDP to
"de-aggregate" the FIB and this may =
raise some issue. However, what =
is
the difference, from the FIB point of view, =
between one /30 pointing to
Rd and four /32 pointing to Rd? I believe =
some FIB implementation
already represent a /30 as four =
/32.
 
Besides, if populating the FTN with specific =
FEC is found to be an
issue, we can only populate the ILM on all P =
routers. For PE/ingress
router, all we really need is BGP to be aware =
of these LSPs and be able
to use them to reach the BGP Next =
Hops.
 
  
It is possible though to imagine a different =
imposition procedure:
 
- get the IP destination address, =
A
 
- find the prefix, P, in the routing table =
which is the best match
    =

(longest
  
  match) for that destination =
address
 
- get the next hop, N, for P, as specified by =
routing
 
- if N has distributed any label bindings for =
prefixes which are
    =

longer =
than
  
  P but begin with the same sequence =
of  bits as P, and if any =
of
    =

these, =
say
  
  Q, is a better match for A than  =
P, then use the label which N
    =

assigned =
to
  
  =
Q.
 
This is a complicated procedure, =
though.   You can't just match =
A
    =

against =
Q,
  
because there might be some prefix  R in =
the routing table, with a
    =

different
<=
font
size=3D2 color=3Dblack face=3D"Courier New">  
next hop, which is  a better match for A =
than P is, but  not as good =
a
    =

match
  
as Q.  The above imposition =
procedure  says that the next hop for =
the
    =

packet
  
is determined  by the  route =
to  R not  by the route  to P  (or =
Q).
    =

It's =
a
  
complex matter  to keep  the =
forwarding tables  in proper =
shape,
    =

given =
that
  
prefixes like Q can come and go =
asynchronously.
    =

 
[Bruno D:] I don't think there is a need to =
change the imposition
procedure at all. The modification of the =
label mapping procedure seems
enough. However, as pointing out by Dutta, an =
additional effort is
needed to sync LDP with the RIB because as =
you said, more specific
prefixes can come and =
go.
 
 
  
There are other  complications as =
well.  For example, what do  you =
do
    =

if =
you
  
get a packet  which is labeled for =
Q,  but the next hop has  =
changed
    =

and =
the
  
new next hop has not distributed a label for =
Q?
 
I suppose we could figure all this out if =
there were an actual problem
    =

which
  
didn't have a better =
solution.
 
 
 
 
 
 
 
______________________________________________=
_
mpls mailing =
list
mpls@lists.ietf.org
https://www1.ietf.or=
g/mailman/listinfo/mpls
    =

 
 
______________________________________________=
_
mpls mailing =
list
mpls@lists.ietf.org
https://www1.ietf.or=
g/mailman/listinfo/mpls
 
 
 
 
------_=_NextPart_001_01C65F24.9EF994D5-- --===============0772916114== 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 --===============0772916114==-- From mpls-bounces@lists.ietf.org Mon Apr 17 17:02:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVapg-0002o8-Op; Mon, 17 Apr 2006 17:00:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU6Ne-0000SJ-64 for mpls@ietf.org; Thu, 13 Apr 2006 14:17:22 -0400 Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU6Na-0005vG-UU for mpls@ietf.org; Thu, 13 Apr 2006 14:17:20 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id LAA18582; Thu, 13 Apr 2006 11:17:06 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [mpls] One LDP Implementation specific question of receivelabelmapping for prefix FECs Date: Thu, 13 Apr 2006 23:47:04 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] One LDP Implementation specific question of receivelabelmapping for prefix FECs Thread-Index: AcZfEUX20VfTi2NrQ/iMTheDfCxI8AAEq2BA From: "Dutta, Pranjal" To: , "Raveendra Torvi" X-Spam-Score: 0.0 (/) X-Scan-Signature: e52b85bc0224ba179c9a8dbf7e5900d9 X-Mailman-Approved-At: Mon, 17 Apr 2006 17:00:24 -0400 Cc: DECRAENE Bruno RD-CORE-ISS , 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="===============0920569540==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0920569540== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65F26.77AD6048" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65F26.77AD6048 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eric, This answers well to the concern. It would depend whether we would like to have an all MPLS network spanning via LDP or not. It is well said that aggregation can be turned off or on based on the whether we would like to have an inter-area LSP or not. At this point I would=20 like to go by that at Rd, LDP is unaware of whether the prefix entries found in its route table for downstream has been summarized to Ru. As David said=20 it has a side effect with LSP-Ping. =20 Regards, Pranjal =20 ________________________________ From: Eric W Gray [mailto:ewgray2k@netscape.net]=20 Sent: Thursday, 13 April, 2006 9:13 PM To: Raveendra Torvi Cc: DECRAENE Bruno RD-CORE-ISS; mpls@ietf.org Subject: Re: [mpls] One LDP Implementation specific question of receivelabelmapping for prefix FECs =20 Let me answer just the first part of this and let the rest take care of itself... :-) LSPs are [terminated] at aggregation boundaries. This may not be desirable in case of an all-MPLS network. To some extent, every box needs to "make up its mind" whether it is a router or a switch. It is important in interoperating between boxes that they are each self-consistent. The aggregator router could decide not to aggregate routing information. That way, it can distribute more specific labels and not worry about inconsistencies between the routes it has advertised and the labels it distributes. However, there are reasons why routers aggregate routing information, and I think it may be difficult to justify why those reasons would not apply equally well to label distribution. It may very well be the case that routing aggregation is not completely justified in specific deployment scenarios. In that case, perhaps it would simply be better to "turn off" route aggregation. -- Eric Raveendra Torvi wrote: Eric, According to your solution LSPs are broken at the aggregation boundary or IGP area boundary, which may not be desirable in case of all-MPLS network. If main goal is to carry transit traffic by the way of LDP-MPLS switching , In case of all-MPLS networks an operator would like to inject only LDP-FECs in other areas (hence achieve the scalability) or avoid summarization LDP-FECs at IGP area boundary .. Please help me understand.=20 Ravi. On 4/13/06, Eric W Gray wrote:=20 Bruno, No, if anything specific had to be said, it would be that Ru MUST NOT advertise a more specific FEC to an upstream peer (Ruu in this case) than it has advertised in routing. I cannot speak - obviously - for every implementation out there, but here's how I believe they _should_ work when dealing with an ABR (or other sumarization point): o The ABR-LSR advertises summarized routes into an adjacent Area. o The ABR-LSR distributes labels corresponding to those routes to LDP peers adjacent to it in that same Area. o The ABR-LSR is then the egress for the corresponding LSPs, in those=20 cases where it has downstream routing entries corresponding to more=20 specific routes. o The ABR-LSR MAY - at that point - inject arriving packets on downstream=20 LSPs - after it performs a routing look-up and discovers an FTN (thus determing an appropriate label and outgoing interface). As I mentioned to Pranjal, this is defined this way for scalability reasons. It is not the=20 intention of MPLS generally to eliminate the need for routing capability in the network at a cost of introducing unscalably large numbers of label distributions throughout the same network. Just as an opinion, a device that is incapable of making this kind of routing decision, has no business being in a position to summarize routes. -- Eric DECRAENE Bruno RD-CORE-ISS wrote: Eric, =20 Thanks for your comments. =20 Additional discussions inlined. =20 Regards, Bruno =20 =20 -----Original Message----- ...[SNIP]... <>presumably the only thing at issue is Ru should label an IP packet that it receives.=20 [Bruno D:] A subsequent issue, is that to continue the LSP further upstream, Ru should allocate a new label and advertise the specific FEC upstream to Ruu. =20 =20 What will happen is that the IP packet gets sent unlabeled to Rd which then labels it according to the specific route which is the best =20 match =20 to the packet's IP destination address. =20 [Bruno D:] That is indeed the current behavior but the problem is that Rd may not be able to forward the IP packet (eg Ru is a VPN PE and Rd is a P). And this may not be an IP packet BTW. =20 =20 The label imposition procedure here is: =20 - get the IP destination address - find the prefix in the routing table which is the best match =20 (longest =20 match) for that destination address - use the label which was assigned to that prefix by the LSR which =20 routing =20 says is the next hop for that prefix. =20 It doesn't make sense for Rd to bind labels to prefixes which =20 are more =20 specific than the one in the routing table, as the label =20 imposition =20 procedure will never make use of such labels. =20 I don't think we want to allow LDP to put prefixes in the routing =20 table, or =20 else we'd have to treat it as a second routing algorithm and that =20 would =20 raise all kinds of issues. =20 [Bruno D:] Such procedure would not change the behavior of the IGP and LDP. LDP would definitely not act as a routing protocol and all routing decisions (next-hop selection, recheability) would still rely on the =20 IGP. LDP would continue advertising labels for FECs and would entirely rely on the RIB for setting up LSPs along the IP route. =20 However, as you very correctly pointed out, we would allow LDP to "de-aggregate" the FIB and this may raise some issue. However, what is =20 the difference, from the FIB point of view, between one /30 pointing to Rd and four /32 pointing to Rd? I believe some FIB implementation already represent a /30 as four /32. =20 Besides, if populating the FTN with specific FEC is found to be an =20 issue, we can only populate the ILM on all P routers. For PE/ingress router, all we really need is BGP to be aware of these LSPs and be able to use them to reach the BGP Next Hops. =20 =20 It is possible though to imagine a different imposition procedure: =20 - get the IP destination address, A =20 - find the prefix, P, in the routing table which is the best match =20 (longest =20 match) for that destination address =20 - get the next hop, N, for P, as specified by routing =20 - if N has distributed any label bindings for prefixes which are =20 longer than =20 P but begin with the same sequence of bits as P, and if any of =20 these, say =20 Q, is a better match for A than P, then use the label which N =20 assigned to =20 Q. =20 This is a complicated procedure, though. You can't just match A =20 against Q, =20 because there might be some prefix R in the routing table, with a =20 different =20 next hop, which is a better match for A than P is, but not as good a =20 match =20 as Q. The above imposition procedure says that the next hop for the =20 packet =20 is determined by the route to R not by the route to P (or Q). =20 It's a =20 complex matter to keep the forwarding tables in proper shape, =20 given that =20 prefixes like Q can come and go asynchronously. =20 [Bruno D:] I don't think there is a need to change the imposition procedure at all. The modification of the label mapping procedure seems enough. However, as pointing out by Dutta, an additional effort is =20 needed to sync LDP with the RIB because as you said, more specific prefixes can come and go. =20 =20 =20 There are other complications as well. For example, what do you do =20 if you =20 get a packet which is labeled for Q, but the next hop has changed =20 and the =20 new next hop has not distributed a label for Q? =20 I suppose we could figure all this out if there were an actual problem =20 which =20 didn't have a better solution. =20 =20 =20 =20 =20 =20 =20 _______________________________________________ mpls mailing list =20 mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls =20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls =20 =20 =20 =20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --=20 101 Billerica Ave, N.Billerica MA -01862 ------_=_NextPart_001_01C65F26.77AD6048 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Eric,

      =            This answers well to the concern. It would depend whether we would like = to have an all MPLS network spanning via LDP or = not.

It is well said that aggregation = can be turned off or on based on the whether we would like to have an = inter-area LSP or not. At this point I would

like to go by that at Rd, LDP is = unaware of whether the prefix entries found in its route table for downstream = has been summarized to Ru. As David said

it has a side effect with = LSP-Ping.

 

Regards,

Pranjal

=

 

From: Eric W Gray [mailto:ewgray2k@netscape.net]
Sent: Thursday, 13 April, = 2006 9:13 PM
To: Raveendra Torvi
Cc: DECRAENE Bruno = RD-CORE-ISS; mpls@ietf.org
Subject: Re: [mpls] One = LDP Implementation specific question of receivelabelmapping for prefix = FECs

 

Let me answer just the first part of this and = let the rest take care of itself... :-)

LSPs = are [terminated] at aggregation boundaries.  This may not be desirable = in case of
an all-MPLS network.

To some extent, every box needs to "make up its mind" whether = it is a router or a switch.
It is important in interoperating between boxes that they are each self-consistent.

The aggregator router could decide not to aggregate routing = information.  That way, it can
distribute more specific labels and not worry about inconsistencies = between the routes it
has advertised and the labels it distributes.

However, there are reasons why routers aggregate routing information, = and I think it may
be difficult to justify why those reasons would not apply equally well = to label distribution.

It may very well be the case that routing aggregation is not completely justified in specific
deployment scenarios. In that case, perhaps it would simply be better to "turn off" route
aggregation.

--
Eric

Raveendra Torvi wrote:

Eric,
According to your solution  LSPs are broken at the aggregation = boundary or IGP area boundary, which may not be desirable in case of all-MPLS = network. If main goal is to carry transit traffic by the way of LDP-MPLS switching , = In case of all-MPLS networks an operator would like to inject only LDP-FECs = in other areas (hence achieve the scalability) or avoid summarization = LDP-FECs at IGP area boundary .. Please help me understand.
Ravi.

On 4/13/06, = Eric W Gray <ewgray2k@netscape.net> = wrote:

Bruno,

    No, if anything specific had to be said, it would be = that Ru MUST NOT advertise a more
specific FEC to an upstream peer (Ruu in this case) than it has = advertised in routing.

    I cannot speak - obviously - for every implementation = out there, but here's how I believe
they _should_ work when dealing with an ABR (or other sumarization = point):

    o   The ABR-LSR advertises summarized = routes into an adjacent Area.
    o   The ABR-LSR distributes labels = corresponding to those routes to LDP
          peers adjacent to it in = that same Area.
    o   The ABR-LSR is then the egress for the corresponding LSPs,  in those
          cases where it has = downstream routing entries corresponding to more
          specific routes.
    o   The ABR-LSR MAY - at that point - = inject arriving packets on downstream
          LSPs - after it = performs a routing look-up and discovers an FTN (thus
          determing an appropriate = label and outgoing interface).

    As I mentioned to Pranjal, this is defined this way = for scalability reasons.  It is not the
intention of MPLS generally to eliminate the need for routing capability = in the network at
a cost of introducing unscalably large numbers of label distributions throughout the same
network.

    Just as an  opinion, a device that is incapable = of making this kind of routing decision,
has no business being in a position to summarize routes.

--

Eric



DECRAENE Bruno RD-CORE-ISS = wrote:

Eric,
 
Thanks for your =
comments.
 
Additional discussions =
inlined.
 
Regards,
Bruno
 
  
-----Original =
Message-----
...[SNIP]...

<>presumably the only thing at issue is = Ru should label an IP packet that it receives. = 

[Bruno D:] A subsequent issue, is that to =
continue the LSP further
upstream, Ru should allocate a new label and =
advertise the specific FEC
upstream to =
Ruu.
 
  
What will happen is that  the IP packet =
gets sent unlabeled to Rd
which then labels it according to the =
specific route which is the =
best
    =

match
  
to the packet's IP destination =
address.
    =

[Bruno D:] That is indeed the current =
behavior but the problem is =
that
Rd may not be able to forward the IP packet =
(eg Ru is a VPN PE and Rd is
a P). And this may not be an IP packet =
BTW.
 
  
The label imposition procedure here =
is:
 
- get the IP destination =
address
- find  the prefix  in the =
routing  table which  is the best  =
match
    =

(longest
  
  match) for that destination =
address
- use the label  which was assigned to =
that prefix by  the LSR =
which
    =

routing
  
  says is the next hop for that =
prefix.
 
It  doesn't make sense  for =
Rd  to bind  labels to  prefixes =
which
    =

are =
more
  
specific  than  the  one =
in  the  routing  table,  as the  =
label
    =

imposition
=
  
procedure will never make use of such =
labels.
 
I don't think we want to allow  LDP to =
put prefixes in the routing
    =

table, =
or
  
else we'd  have to  treat it =
as  a second  routing algorithm and  =
that
    =

would
  
raise all kinds of =
issues.
    =

[Bruno D:] Such procedure would not change =
the behFrom mpls-bounces@lists.ietf.org Mon Apr 17 17:02:37 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FVapg-0002o8-Op; Mon, 17 Apr 2006 17:00:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FU6Ne-0000SJ-64
	for mpls@ietf.org; Thu, 13 Apr 2006 14:17:22 -0400
Received: from generic.riverstonenet.com ([66.17.149.13]
	helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FU6Na-0005vG-UU
	for mpls@ietf.org; Thu, 13 Apr 2006 14:17:20 -0400
Received: from gondor.rs.riverstonenet.com by riverstonenet.com
	(8.9.3+Sun/SMI-SVR4-Yago)
	id LAA18582; Thu, 13 Apr 2006 11:17:06 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [mpls] One LDP Implementation specific question of
	receivelabelmapping for prefix FECs
Date: Thu, 13 Apr 2006 23:47:04 +0530
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [mpls] One LDP Implementation specific question of
	receivelabelmapping for prefix FECs
Thread-Index: AcZfEUX20VfTi2NrQ/iMTheDfCxI8AAEq2BA
From: "Dutta, Pranjal" 
To: , "Raveendra Torvi" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e52b85bc0224ba179c9a8dbf7e5900d9
X-Mailman-Approved-At: Mon, 17 Apr 2006 17:00:24 -0400
Cc: DECRAENE Bruno RD-CORE-ISS ,
	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="===============0920569540=="
Errors-To: mpls-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============0920569540==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C65F26.77AD6048"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C65F26.77AD6048
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Eric,

                 This answers well to the concern. It would depend
whether we would like to have an all MPLS network spanning via LDP or
not.

It is well said that aggregation can be turned off or on based on the
whether we would like to have an inter-area LSP or not. At this point I
would=20

like to go by that at Rd, LDP is unaware of whether the prefix entries
found in its route table for downstream has been summarized to Ru. As
David said=20

it has a side effect with LSP-Ping.

=20

Regards,

Pranjal

=20

________________________________

From: Eric W Gray [mailto:ewgray2k@netscape.net]=20
Sent: Thursday, 13 April, 2006 9:13 PM
To: Raveendra Torvi
Cc: DECRAENE Bruno RD-CORE-ISS; mpls@ietf.org
Subject: Re: [mpls] One LDP Implementation specific question of
receivelabelmapping for prefix FECs

=20

Let me answer just the first part of this and let the rest take care of
itself... :-)

LSPs are [terminated] at aggregation boundaries.  This may not be
desirable in case of
an all-MPLS network.

To some extent, every box needs to "make up its mind" whether it is a
router or a switch.
It is important in interoperating between boxes that they are each
self-consistent.

The aggregator router could decide not to aggregate routing information.
That way, it can
distribute more specific labels and not worry about inconsistencies
between the routes it
has advertised and the labels it distributes.

However, there are reasons why routers aggregate routingavior of the IGP and
LDP.
LDP would definitely not act as a routing =
protocol and all routing
decisions (next-hop selection, recheability) =
would still rely on the
 
IGP. LDP would continue advertising labels =
for FECs and would entirely
rely on the RIB for setting up LSPs along the =
IP route.
 
However, as you very correctly pointed out, =
we would allow LDP to
"de-aggregate" the FIB and this may =
raise some issue. However, what =
is
 
the difference, from the FIB point of view, =
between one /30 pointing to
Rd and four /32 pointing to Rd? I believe =
some FIB implementation
already represent a /30 as four =
/32.
 
Besides, if populating the FTN with specific =
FEC is found to be an
 
issue, we can only populate the ILM on all P =
routers. For PE/ingress
router, all we really need is BGP to be aware =
of these LSPs and be able
to use them to reach the BGP Next =
Hops.
 
  
It is possible though to imagine a different =
imposition procedure:
 
- get the IP destination address, =
A
 wrote:=20

Bruno,

    No, if anything specific had to be said, it would be that Ru MUST
NOT advertise a more
specific FEC to an upstream peer (Ruu in this case) than it has
advertised in routing.

    I cannot speak - obviously - for every implementation out there, but
here's how I believe
they _should_ work when dealing with an ABR (or other sumarization
point):

    o   The ABR-LSR advertises summarized routes into an adjacent Area.
    o   The ABR-LSR distributes labels corresponding to those routes to
LDP
          peers adjacent to it in that same Area.
    o   The ABR-LSR is then the egress for the corresponding LSPs,  in
those=20
          cases where it has downstream routing entries corresponding to
more=20
          specific routes.
    o   The ABR-LSR MAY - at that point - inject arriving packets on
downstream=20
          LSPs - after it performs a routing look-up and discovers an
FTN (thus
          determing an appropriate label and outgoing interface).

    As I mentioned to Pranjal, this is defined this way for scalability
reasons.  It is not the=20
intention of MPLS generally to eliminate the need for routing capability
in the network at
a cost of introducing unscalably large numbers of label distributions
throughout the same
network.

    Just as an  opinion, a device that is incapable of making this kind
of routing decision,
has no business being in a position to summarize routes.

--

Eric



DECRAENE Bruno RD-CORE-ISS wrote:

Eric,
=20
Thanks for your comments.
=20
Additional discussions inlined.
=20
Regards,
Bruno
=20
 =20

	-----Original Message-----
	...[SNIP]...

	<>presumably the only thing at issue is Ru should label an IP
packet that it receives.=20

[Bruno D:] A subsequent issue, is that to continue the LSP further
upstream, Ru should allocate a new label and advertise the specific FEC
upstream to Ruu.
=20
 =20

	What will happen is that  the IP packet gets sent unlabeled to
Rd
	which then labels it according to the specific route which is
the best
	   =20

match
 =20

	to the packet's IP destination address.
	   =20

[Bruno D:] That is indeed the current behavior but the problem is that
Rd may not be able to forward the IP packet (eg Ru is a VPN PE and Rd is
a P). And this may not be an IP packet BTW.
=20
 =20

	The label imposition procedure here is:
	=20
	- get the IP destination address
	- find  the prefix  in the routing  table which  is the best
match
	   =20

(longest
 =20

	  match) for that destination address
	- use the label  which was assigned to that prefix by  the LSR
which
	   =20

routing
 =20

	  says is the next hop for that prefix.
	=20
	It  doesn't make sense  for Rd  to bind  labels to  prefixes
which
	   =20

are more
 =20

	specific  than  the  one in  the  routing  table,  as the  label
	   =20

imposition
 =20

	procedure will never make use of such labels.
	=20
	I don't think we want to allow  LDP to put prefixes in the
routing
	   =20

table, or
 =20

	else we'd  have to  treat it as  a second  routing algorithm and
that
	   =20

would
 =20

	raise all kinds of issues.
	   =20

[Bruno D:] Such procedure would not change the behavior of the IGP and
LDP.
LDP would definitely not act as a routing protocol and all routing
decisions (next-hop selection, recheability) would still rely on the
=20
IGP. LDP would continue advertising labels for FECs and would entirely
rely on the RIB for setting up LSPs along the IP route.
=20
However, as you very correctly pointed out, we would allow LDP to
"de-aggregate" the FIB and this may raise some issue. However, what is
=20
the difference, from the FIB point of view, between one /30 pointing to
Rd and four /32 pointing to Rd? I believe some FIB implementation
already represent a /30 as four /32.
=20
Besides, if populating the FTN with specific FEC is found to be an
=20
issue, we can only populate the ILM on all P routers. For PE/ingress
router, all we really need is BGP to be aware of these LSPs and be able
to use them to reach the BGP Next Hops.
=20
 =20

	It is possible though to imagine a different imposition
procedure:
	=20
	- get the IP destination address, A
	=20
	- find the prefix, P, in the routing table which is the best
match
	   =20

(longest
 =20

	  match) for that destination address
	=20
	- get the next hop, N, for P, as specified by routing
	=20
	- if N has distributed any label bindings for prefixes which are
	   =20

longer than
 =20

	  P but begin with the same sequence of  bits as P, and if any
of
	   =20

these, say
 =20

	  Q, is a better match for A than  P, then use the label which N
	   =20

assigned to
 =20

	  Q.
	=20
	This is a complicated procedure, though.   You can't just match
A
	   =20

against Q,
 =20

	because there might be some prefix  R in the routing table, with
a
	   =20

different
 =20

	next hop, which is  a better match for A than P is, but  not as
good a
	   =20

match
 =20

	as Q.  The above imposition procedure  says that the next hop
for the
	   =20

packet
 =20

	is determined  by the  route to  R not  by the route  to P  (or
Q).
	   =20

It's a
 =20

	complex matter  to keep  the forwarding tables  in proper shape,
	   =20

given that
 =20

	prefixes like Q can come and go asynchronously.
	   =20

[Bruno D:] I don't think there is a need to change the imposition
procedure at all. The modification of the label mapping procedure seems
enough. However, as pointing out by Dutta, an additional effort is
=20
needed to sync LDP with the RIB because as you said, more specific
prefixes can come and go.
=20
=20
 =20

	There are other  complications as well.  For example, what do
you do
	   =20

if you
 =20

	get a packet  which is labeled for Q,  but the next hop has
changed
	   =20

and the
 =20

	new next hop has not distributed a label for Q?
	=20
	I suppose we could figure all this out if there were an actual
problem
	   =20

which
 =20

	didn't have a better solution.
	=20
	=20
	=20
	=20
	=20
	=20
	=20
	_______________________________________________
	mpls mailing list
	=20
	mpls@lists.ietf.org
	https://www1.ietf.org/mailman/listinfo/mpls
	   =20

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


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






--=20
101 Billerica Ave,
N.Billerica MA -01862


------_=_NextPart_001_01C65F26.77AD6048
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable




















Hi =
Eric,



      =
          
This answers well to the concern. It would depend whether we would like =
to have
an all MPLS network spanning via LDP or =
not.



It is well said that aggregation =
can be
turned off or on based on the whether we would like to have an =
inter-area LSP
or not. At this point I would 



like to go by that at Rd, LDP is =
unaware
of whether the prefix entries found in its route table for downstream =
has been
summarized to Ru. As David said 



it has a side effect with =
LSP-Ping.



 



Regards,


Pranjal
=



 















From: Eric W Gray [mailto:ewgray2k@netscape.net] 

Sent: Thursday, 13 April, =
2006
9:13 PM

To: Raveendra Torvi

Cc: DECRAENE Bruno =
RD-CORE-ISS;
mpls@ietf.org

Subject: Re: [mpls] One =
LDP
Implementation specific question of receivelabelmapping for prefix =
FECs






 



Let me answer just the first part of this and =
let the
rest take care of itself... :-)



LSPs =
are
[terminated] at aggregation boundaries.  This may not be desirable =
in case
of

an all-MPLS network.



To some extent, every box needs to "make up its mind" whether =
it is a
router or a switch.

It is important in interoperating between boxes that they are each
self-consistent.



The aggregator router could decide not to aggregate routing =
information. 
That way, it can

distribute more specific labels and not worry about inconsistencies =
between the
routes it

has advertised and the labels it distributes.



However, there are reasons why routers aggregate routing information, =
and I
think it may

be difficult to justify why those reasons would not apply equally well =
to label
distribution.



It may very well be the case that routing aggregation is not completely
justified in specific

deployment scenarios. In that case, perhaps it would simply be better to
"turn off" route

aggregation.



--

Eric



Raveendra Torvi wrote:







Eric,

According to your solution  LSPs are broken at the aggregation =
boundary or
IGP area boundary, which may not be desirable in case of all-MPLS =
network. If
main goal is to carry transit traffic by the way of LDP-MPLS switching , =
In
case of all-MPLS networks an operator would like to inject only LDP-FECs =
in
other areas (hence achieve the scalability) or avoid summarization =
LDP-FECs at
IGP area boundary .. Please help me understand. 

Ravi.










On 4/13/06, =
Eric W Gray <ewgray2k@netscape.net> =
wrote:







Bruno,



    No, if anything specific had to be said, it would be =
that Ru
MUST NOT advertise a more

specific FEC to an upstream peer (Ruu in this case) than it has =
advertised in
routing.



    I cannot speak - obviously - for every implementation =
out
there, but here's how I believe

they _should_ work when dealing with an ABR (or other sumarization =
point):



    o   The ABR-LSR advertises summarized =
routes into
an adjacent Area.

    o   The ABR-LSR distributes labels =
corresponding
to those routes to LDP

          peers adjacent to it in =
that same
Area.

    o   The ABR-LSR is then the egress for the
corresponding LSPs,  in those 

          cases where it has =
downstream
routing entries corresponding to more 

          specific routes.

    o   The ABR-LSR MAY - at that point - =
inject
arriving packets on downstream 

          LSPs - after it =
performs a
routing look-up and discovers an FTN (thus

          determing an appropriate =
label and
outgoing interface).



    As I mentioned to Pranjal, this is defined this way =
for
scalability reasons.  It is not the 

intention of MPLS generally to eliminate the need for routing capability =
in the
network at

a cost of introducing unscalably large numbers of label distributions
throughout the same

network.



    Just as an  opinion, a device that is incapable =
of
making this kind of routing decision,

has no business being in a position to summarize routes.



--









Eric













DECRAENE Bruno RD-CORE-ISS =
wrote:






Eric,
 
Thanks for your =
comments.
 
Additional discussions =
inlined.
 
Regards,
Bruno
 
  






-----Original =
Message-----
...[SNIP]...






<>presumably the only thing at issue is =
Ru
should label an IP packet that it receives. =







[Bruno D:] A subsequent issue, is that to =
continue the LSP further
upstream, Ru should allocate a new label and =
advertise the specific FEC
upstream to =
Ruu.
 
  



What will happen is that  the IP packet =
gets sent unlabeled to Rd
which then labels it according to the =
specific route which is the =
best
    =




match
  



to the packet's IP destination =
address.
    =




[Bruno D:] That is indeed the current =
behavior but the problem is =
that
Rd may not be able to forward the IP packet =
(eg Ru is a VPN PE and Rd is
a P). And this may not be an IP packet =
BTW.
 
  



The label imposition procedure here =
is:
 
- get the IP destination =
address
- find  the prefix  in the =
routing  table which  is the best  =
match
    =




(longest
  



  match) for that destination =
address
- use the label  which was assigned to =
that prefix by  the LSR =
which
    =




routing
  



  says is the next hop for that =
prefix.
 
It  doesn't make sense  for =
Rd  to bind  labels to  prefixes =
which
    =




are =
more
  



specific  than  the  one =
in  the  routing  table,  as the  =
label
    =




imposition
=
  



procedure will never make use of such =
labels.
 
I don't think we want to allow  LDP to =
put prefixes in the routing
    =




table, =
or
  



else we'd  have to  treat it =
as  a second  routing algorithm and  =
that
    =




would
  



raise all kinds of =
issues.
    =




[Bruno D:] Such procedure would not change =
the behier New"> 
- find the prefix, P, in the routing table =
which is the best match
    =




(longest
  



  match) for that destination =
address
 
- get the next hop, N, for P, as specified by =
routing
 
- if N has distributed any label bindings for =
prefixes which are
    =




longer =
than
  



  P but begin with the same sequence =
of  bits as P, and if any =
of
    =




these, =
say
  



  Q, is a better match for A than  =
P, then use the label which N
    =




assigned =
to
  



  =
Q.
 
This is a complicated procedure, =
though.   You can't just match =
A
    =




LDP.
LDP would definitely not act as a routing =
protocol and all routing
decisions (next-hop selection, recheability) =
would still rely on the
 
IGP. LDP would continue advertising labels =
for FECs and would entirely
rely on the RIB for setting up LSPs along the =
IP route.
 
However, as you very correctly pointed out, =
we would allow LDP to
"de-aggregate" the FIB and this may =
raise some issue. However, what =
is
 
the difference, from the FIB point of view, =
between one /30 pointing to
Rd and four /32 pointing to Rd? I believe =
some FIB implementation
already represent a /30 as four =
/32.
 
Besides, if populating the FTN with specific =
FEC is found to be an
 
issue, we can only populate the ILM on all P =
routers. For PE/ingress
router, all we really need is BGP to be aware =
of these LSPs and be able
to use them to reach the BGP Next =
Hops.
 
  



It is possible though to imagine a different =
imposition procedure:
 
- get the IP destination address, =
A
against =
Q,
  



because there might be some prefix  R in =
the routing table, with a
    =




different
<=
font
size=3D2 color=3Dblack face=3D"Courier New">  



next hop, which is  a better match for A =
than P is, but  not as good =
a
    =




match
  



as Q.  The above imposition =
procedure  says that the next hop for =
the
    =




packet
  



is determined  by the  route =
to  R not  by the route  to P  (or =
Q).
    =




It's =
a
  



complex matter  to keep  the =
forwarding tables  in proper =
shape,
    =




given =
that
  



prefixes like Q can come and go =
asynchronously.
    =



 
- find the prefix, P, in the routing table =
which is the best match
    =

(longest
  
  match) for that destination =
address
 
- get the next hop, N, for P, as specified by =
routing
 
- if N has distributed any label bindings for =
prefixes which are
    =

longer =
than
  
  P but begin with the same sequence =
of  bits as P, and if any =
of
    =

these, =
say
  
  Q, is a better match for A than  =
P, then use the label which N
    =

assigned =
to
  
  =
Q.
 
This is a complicated procedure, =
though.   You can't just match =
A
    =

against =
Q,
  
because there might be some prefix  R in =
the routing table, with a
    =

different
<=
font
size=3D2 color=3Dblack face=3D"Courier New">  
next hop, which is  a better match for A =
than P is, but  not as good =
a
    =

match
  
as Q.  The above imposition =
procedure  says that the next hop for =
the
    =

packet
  
is determined  by the  route =
to  R not  by the route  to P  (or =
Q).
    =

It's =
a
  
complex matter  to keep  the =
forwarding tables  in proper =
shape,
    =

given =
that
  
prefixes like Q can come and go =
asynchronously.
    =

[Bruno D:] I don't think there is a need to =
change the imposition
procedure at all. The modification of the =
label mapping procedure seems
enough. However, as pointing out by Dutta, an =
additional effort is
 
needed to sync LDP with the RIB because as =
you said, more specific
prefixes can come and =
go.
 
 
  
There are other  complications as =
well.  For example, what do  you =
do
    =

if =
you
  
get a packet  which is labeled for =
Q,  but the next hop has  =
changed
    =

and =
the
  
new next hop has not distributed a label for =
Q?
 
I suppose we could figure all this out if =
there were an actual problem
    =

which
  
didn't have a better =
solution.
 
 
 
 
 
 
 
______________________________________________=
_
mpls mailing =
list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
    =

______________________________________________=
_
mpls mailing =
list
mpls@lists.ietf.org
<= pre>https://www1.ietf.org/mailman/listinfo/mpls
 
 
 
 


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




--
101 Billerica = Ave,
N.Billerica MA -01862

------_=_NextPart_001_01C65F26.77AD6048-- --===============0920569540== 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 --===============0920569540==-- From mpls-bounces@lists.ietf.org Mon Apr 17 17:02:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVapi-0002oE-5o; Mon, 17 Apr 2006 17:00:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUH6x-0008AN-LC for mpls@ietf.org; Fri, 14 Apr 2006 01:44:51 -0400 Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUH6v-0003y1-Bb for mpls@ietf.org; Fri, 14 Apr 2006 01:44:51 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id WAA26577; Thu, 13 Apr 2006 22:44:40 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [mpls] One LDP Implementation specific question of receivelabelmapping for prefix FECs Date: Fri, 14 Apr 2006 11:14:39 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] One LDP Implementation specific question of receivelabelmapping for prefix FECs Thread-Index: AcZfEUX20VfTi2NrQ/iMTheDfCxI8AAdAiMA From: "Dutta, Pranjal" To: , "Raveendra Torvi" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a363ababf76d7d43174ab37103dea9c X-Mailman-Approved-At: Mon, 17 Apr 2006 17:00:24 -0400 Cc: DECRAENE Bruno RD-CORE-ISS , 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="===============1181172951==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1181172951== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65F86.85273E8D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65F86.85273E8D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eric, This answers well to the concern. It would depend whether we would like to have an all MPLS network spanning via LDP or not. It is well said that aggregation can be turned off or on based on the whether we would like to have an inter-area LSP or not. At this point I would=20 like to go by that at Rd, LDP is unaware of whether the prefix entries found in its route table for downstream has been summarized to Ru. As David said=20 it has a side effect with LSP-Ping. =20 Regards, Pranjal =20 =20 =20 ________________________________ From: Eric W Gray [mailto:ewgray2k@netscape.net]=20 Sent: Thursday, 13 April, 2006 9:13 PM To: Raveendra Torvi Cc: DECRAENE Bruno RD-CORE-ISS; mpls@ietf.org Subject: Re: [mpls] One LDP Implementation specific question of receivelabelmapping for prefix FECs =20 Let me answer just the first part of this and let the rest take care of itself... :-) LSPs are [terminated] at aggregation boundaries. This may not be desirable in case of an all-MPLS network. To some extent, every box needs to "make up its mind" whether it is a router or a switch. It is important in interoperating between boxes that they are each self-consistent. The aggregator router could decide not to aggregate routing information. That way, it can distribute more specific labels and not worry about inconsistencies between the routes it has advertised and the labels it distributes. However, there are reasons why routers aggregate routing information, and I think it may be difficult to justify why those reasons would not apply equally well to label distribution. It may very well be the case that routing aggregation is not completely justified in specific deployment scenarios. In that case, perhaps it would simply be better to "turn off" route aggregation. -- Eric Raveendra Torvi wrote: Eric, According to your solution LSPs are broken at the aggregation boundary or IGP area boundary, which may not be desirable in case of all-MPLS network. If main goal is to carry transit traffic by the way of LDP-MPLS switching , In case of all-MPLS networks an operator would like to inject only LDP-FECs in other areas (hence achieve the scalability) or avoid summarization LDP-FECs at IGP area boundary .. Please help me understand.=20 Ravi. On 4/13/06, Eric W Gray wrote:=20 Bruno, No, if anything specific had to be said, it would be that Ru MUST NOT advertise a more specific FEC to an upstream peer (Ruu in this case) than it has advertised in routing. I cannot speak - obviously - for every implementation out there, but here's how I believe they _should_ work when dealing with an ABR (or other sumarization point): o The ABR-LSR advertises summarized routes into an adjacent Area. o The ABR-LSR distributes labels corresponding to those routes to LDP peers adjacent to it in that same Area. o The ABR-LSR is then the egress for the corresponding LSPs, in those=20 cases where it has downstream routing entries corresponding to more=20 specific routes. o The ABR-LSR MAY - at that point - inject arriving packets on downstream=20 LSPs - after it performs a routing look-up and discovers an FTN (thus determing an appropriate label and outgoing interface). As I mentioned to Pranjal, this is defined this way for scalability reasons. It is not the=20 intention of MPLS generally to eliminate the need for routing capability in the network at a cost of introducing unscalably large numbers of label distributions throughout the same network. Just as an opinion, a device that is incapable of making this kind of routing decision, has no business being in a position to summarize routes. -- Eric DECRAENE Bruno RD-CORE-ISS wrote: Eric, =20 Thanks for your comments. =20 Additional discussions inlined. =20 Regards, Bruno =20 =20 -----Original Message----- ...[SNIP]... <>presumably the only thing at issue is Ru should label an IP packet that it receives.=20 [Bruno D:] A subsequent issue, is that to continue the LSP further upstream, Ru should allocate a new label and advertise the specific FEC upstream to Ruu. =20 =20 What will happen is that the IP packet gets sent unlabeled to Rd which then labels it according to the specific route which is the best =20 match =20 to the packet's IP destination address. =20 [Bruno D:] That is indeed the current behavior but the problem is that Rd may not be able to forward the IP packet (eg Ru is a VPN PE and Rd is a P). And this may not be an IP packet BTW. =20 =20 The label imposition procedure here is: =20 - get the IP destination address - find the prefix in the routing table which is the best match =20 (longest =20 match) for that destination address - use the label which was assigned to that prefix by the LSR which =20 routing =20 says is the next hop for that prefix. =20 It doesn't make sense for Rd to bind labels to prefixes which =20 are more =20 specific than the one in the routing table, as the label =20 imposition =20 procedure will never make use of such labels. =20 I don't think we want to allow LDP to put pr>[Bruno D:] I don't think there is a need to = change the imposition
procedure at all. The modification of the =
label mapping procedure seems
enough. However, as pointing out by Dutta, an =
additional effort is
 
needed to sync LDP with the RIB because as =
you said, more specific
prefixes can come and =
go.
 
 
  
There are other  complications as =
well.  For example, what do  you =
do
    =

if =
you
  
get a packet  which is labeled for =
Q,  but the next hop has  =
changed
    =

and =
the
  
new next hop has not distributed a label for =
Q?
 
I suppose we could figure all this out if =
there were an actual problem
    =

which
  
didn't have a better =
solution.
=20
	mpls@lists.ietf.org
	https://www1.ietf.org/mailman/listinfo/mpls
	   =20

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


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






--=20
101 Billerica Ave,
N.Billerica MA -01862


------_=_NextPart_001_01C65F86.85273E8D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable




















Hi =
Eric,



      =
          
This answers well to the concern. It would depend whether we would like =
to have
an all MPLS network spanning via LDP or =
not.



It is well said that aggregation =
can be
turned off or on based on the whether we would like to have an =
inter-area LSP
or not. At this point I would 



like to go by that at Rd, LDP is =
unaware
of whether the prefix entries found in its route table for downstream =
has been
summarized to Ru. As David said 



it has a side effect with =
LSP-Ping.



 



Regards,


Pranjal
=



 



 



 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [mpls] One LDP Implementation specific question of
	receivelabelmapping for prefix FECs
Thread-Index: AcZfEUX20VfTi2NrQ/iMTheDfCxI8AAdAiMA
From: "Dutta, Pranjal" 
To: , "Raveendra Torvi" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8a363ababf76d7d43174ab37103dea9c
X-Mailman-Approved-At: Mon, 17 Apr 2006 17:00:24 -0400
Cc: DECRAENE Bruno RD-CORE-ISS ,
	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="===============1181172951=="
Errors-To: mpls-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============1181172951==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C65F86.85273E8D"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C65F86.85273E8D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Eric,

                 This answers well to the concern. It would depend
whether we would like to have an all MPLS network spanning via LDP or
not.

It is well said that aggregation can be turned off or on based on the
whether we would like to have an inter-area LSP or not. At this point I
would=20

like to go by that at Rd, LDP is unaware of whether the prefix entries
found in its route table for downstream has been summarized to Ru. As
David said=20

it has a side effect with LSP-Ping.

=20

Regards,

Pranjal

=20

=20

=20

________________________________

From: Eric W Gray [mailto:ewgray2k@netscape.net]=20
Sent: Thursday, 13 April, 2006 9:13 PM
To: Raveendra Torvi
Cc: DECRAENE Bruno RD-CORE-ISS; mpls@ietf.org
Subject: Re: [mpls] One LDP Implementation specific question of
receivelabelmapping for prefix FECs

=20

Let me answer just the first part of this and let the rest take care of
itself... :-)

LSPs are [terminated] at aggregation boundaries.  This may not be
desirable in case of
an all-MPLS network.

To some extent, every box needs to "make up its mind" whether it is a
router or a switch.
It is important in interoperating between boxp>















From: Eric W Gray [mailto:ewgray2k@netscape.net] 

Sent: Thursday, 13 April, =
2006
9:13 PM

To: Raveendra Torvi

Cc: DECRAENE Bruno =
RD-CORE-ISS;
mpls@ietf.org

Subject: Re: [mpls] One =
LDP
Implementation specific question of receivelabelmapping for prefix =
FECs






 



Let me answer just the first part of this and =
let the
rest take care of itself... :-)



LSPs =
are
[terminated] at aggregation boundaries.  This may not be desirable =
in case
of

an all-MPLS network.



To some extent, every box needs to "make up its mind" whether =
it is a
router or a switch.

It is important in interoperating between boxes that they are each
self-consistent.



The aggregator router could decide not to aggregate routing =
information. 
That way, it can

distribute more specific labels and not worry about inconsistencies =
between the
routes it

has advertised and the labels it distributes.



However, there are reasons why routers aggregate routing information, =
and I
think it may

be difficult to justify why those reasons would not apply equally well =
to label
distribution.



It may very well be the case that routing aggregation is not completely
justified in specific

deployment scenarios. In that case, perhaps it would simply be better to
"turn off" route

aggregation.



--

Eric



Raveendra Torvi wrote:







Eric,

According to your solution  LSPs are broken at the aggregation =
boundary or
IGP area boundary, which may not be desirable in case of all-MPLS =
network. If
main goal is to carry transit traffic by the way of LDP-MPLS switching , =
In
case of all-MPLS networks an operator would like to inject only LDP-FECs =
in
other areas (hence achieve the scalability) or avoid summarization =
LDP-FECs at
IGP area boundary .. Please help me understand. 

Ravi.










On 4/13/06, =
Eric W Gray <ewgray2k@netscape.net> =
wrote:







Bruno,



    No, if anything specific had to be said, it would be =
that Ru
MUST NOT advertise a more

specific FEC to an upstream peer (Ruu in this case) than it has =
advertised in
routing.



    I cannot speak - obviously - for every implementationes that they are each
self-consistent.

The aggregator router could decide not to aggregate routing information.
That way, it can
distribute more specific labels and not worry about inconsistencies
between the routes it
has advertised and the labels it distributes.

However, there are reasons why routers aggregate routing information,
and I think it may
be difficult to justify why those reasons would not apply equally well
to label distribution.

It may very well be the case that routing aggregation is not completely
justified in specific
deployment scenarios. In that case, perhaps it would simply be better to
"turn off" route
aggregation.

--
Eric

Raveendra Torvi wrote:



Eric,
According to your solution  LSPs are broken at the aggregation boundary
or IGP area boundary, which may not be desirable in case of all-MPLS
network. If main goal is to carry transit traffic by the way of LDP-MPLS
switching , In case of all-MPLS networks an operator would like to
inject only LDP-FECs in other areas (hence achieve the scalability) or
avoid summarization LDP-FECs at IGP area boundary .. Please help me
understand.=20
Ravi.



On 4/13/06, Eric W Gray  wrote:=20

Bruno,

    No, if anything specific had to be said, it would be that Ru MUST
NOT advertise a more
specific FEC to an upstream peer (Ruu in this case) than it has
advertised in routing.

    I cannot speak - obviously - for every implementation out there, but
here's how I believe
they _should_ work when dealing with an ABR (or other sumarization
point):

    o   The ABR-LSR advertises summarized routes into an adjacent Area.
    o   The ABR-LSR distributes labels corresponding to those routes to
LDP
          peers adjacent to it in that same Area.
    o   The ABR-LSR is then the egress for the corresponding LSPs,  in
those=20
          cases where it has downstream routing entries corresponding to
more=20
          specific routes.
    o   The ABR-LSR MAY - at that point - inject arriving packets on
downstream=20
          LSPs - after it performs a routing look-up and discovers an
FTN (thus
          determing an appropriate label and outgoing interface).

    As I mentioned to Pranjal, this is defined this way for scalability
reasons.  It is not the=20
intention of MPLS generally to eliminate the need for routing capability
in the network at
a cost of introducing unscalably large numbers of label distributions
throughout the same
network.

    Just as an  opinion, a device that is incapable of making this kind
of routing decision,
has no business being in a position to summarize routes.

--

Eric



DECRAENE Bruno RD-CORE-ISS wrote:

Eric,
=20
Thanks for your comments.
=20
Additional discussions inlined.
=20
Regards,
Bruno
=20
 =20

	-----Original Message-----
	...[SNIP]...

	<>presumably the only thing at issue is Ru should label an IP
packet that it receives.=20

[Bruno D:] A subsequent issue, is that to continue the LSP further
upstream, Ru should allocate a new label and advertise the specific FEC
upstream to Ruu.
=20
 =20

	What will happen is that  the IP packet gets sent unlabeled to
Rd
	which then labels it according to the specific route which is
the best
	   =20

match
 =20

	to the packet's IP destination address.
	   =20

[Bruno D:] That is indeed the current behavior but the problem is that
Rd may not be able to forward the IP packet (eg Ru is a VPN PE and Rd is
a P). And this may not be an IP packet BTW.
=20
 =20

	The label imposition procedure here is:
	=20
	- get the IP destination address
	- find  the prefix  in the routing  table which  is the best
match
	   =20

(longest
 =20

	  match) for that destination address
	- use the label  which was assigned to that prefix by  the LSR
which
	   =20

routing
 =20

	  says is the next hop for that prefix.
	=20
	It  doesn't make sense  for Rd  to bind  labels to  prefixes
which
	   =20

are more
 =20

	specific  than  the  one in  the  routing  table,  as the  label
	   =20

imposition
 =20

	procedure will never make use of such labels.
	=20
	I don't think we want to allow  LDP to put prefixes in the
routing
	   =20

table, or
 =20

	else we'd  have to  treat it as  a second  routing algorithm and
that
	   =20

would
 =20

	raise all kinds of issues.
	   =20

[Bruno D:] Such procedure would not change the behavior of the IGP and
LDP.
LDP would definitely not act as a routing protocol and all routing
decisions (next-hop selection, recheability) would still rely on the
=20
IGP. LDP would continue advertising labels for FECs and would entirely
rely on the RIB for setting up LSPs along the IP route.
=20
However, as you very correctly pointed out, we would allow LDP to
"de-aggregate" the FIB and this may raise some issue. However, what is
=20
the difference, from the FIB point of view, between one /30 pointing to
Rd and four /32 pointing to Rd? I believe some FIB implementation
already represent a /30 as four /32.
=20
Besides, if populating the FTN with specific FEC is found to be an
=20
issue, we can only populate the ILM on all P routers. For PE/ingress
router, all we really need is BGP to be aware of these LSPs and be able
to use them to reach the BGP Next Hops.
=20
 =20

	It is possible though to imagine a different imposition
procedure:
	=20
	- get the IP destination address, A
	=20
	- find the prefix, P, in the routing table which is the best
match
	   =20

(longest
 =20

	  match) for that destination address
	=20
	- get the next hop, N, for P, as specified by routing
	=20
	- if N has distributed any label bindings for prefixes which are
	   =20

longer than
 =20

	  P but begin with the same sequence of  bits as P, and if any
of
	   =20

these, say
 =20

	  Q, is a better match for A than  P, then use the label which N
	   =20

assigned to
 =20

	  Q.
	=20
	This is a complicated procedure, though.   You can't just match
A
	   =20

against Q,
 =20

	because there might be some prefix  R in the routing table, with
a
	   =20

different
 =20

	next hop, which is  a better match for A than P is, but  not as
good a
	   =20

match
 =20

	as Q.  The above imposition procedure  says that the next hop
for the
	   =20

packet
 =20

	is determined  by the  route to  R not  by the route  to P  (or
Q).
	   =20

It's a
 =20

	complex matter  to keep  the forwarding tables  in proper shape,
	   =20

given that
 =20

	prefixes like Q can come and go asynchronously.
	   =20

[Bruno D:] I don't think there is a need to change the imposition
procedure at all. The modification of the label mapping procedure seems
enough. However, as pointing out by Dutta, an additional effort is
=20
needed to sync LDP with the RIB because as you said, more specific
prefixes can come and go.
=20
=20
 =20

	There are other  complications as well.  For example, what do
you do
	   =20

if you
 =20

	get a packet  which is labeled for Q,  but the next hop has
changed
	   =20

and the
 =20

	new next hop has not distributed a label for Q?
	=20
	I suppose we could figure all this out if there were an actual
problem
	   =20

which
 =20

	didn't have a better solution.
	=20
	=20
	=20
	=20
	=20
	=20
	=20
	_______________________________________________
	mpls mailing list
	=20
	mpls@lists.ietf.org
	https://www1.ietf.org/mailman/listinfo/mpls
	   =20

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


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






--=20
101 Billerica Ave,
N.Billerica MA -01862


------_=_NextPart_001_01C65F86.85273E8D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable




















Hi =
Eric,



      =
          
This answers well to the concern. It would depend whether we would like =
to have
an all MPLS network spanning via LDP or =
not.



It is well said that aggregation =
can be
turned off or on based on the whether we would like to have an =
inter-area LSP
or not. At this point I would 



like to go by that at Rd, LDP is =
unaware
of whether the prefix entries found in its route table for downstream =
has been
summarized to Ru. As David said 



it has a side effect with =
LSP-Ping.



 



Regards,


Pranjal
=



 



 



 















From: Eric W Gray [mailto:ewgray2k@netscape.net] 

Sent: Thursday, 13 April, =
2006
9:13 PM

To: Raveendra Torvi

Cc: DECRAENE Bruno =
RD-CORE-ISS;
mpls@ietf.org

Subject: Re: [mpls] One =
LDP
Implementation specific question of receivelabelmapping for prefix =
FECs






 



Let me answer just the first part of this and =
let the
rest take care of itself... :-)



LSPs =
are
[terminated] at aggregation boundaries.  This may not be desirable =
in case
of

an all-MPLS network.



To some extent, every box needs to "make up its mind" whether =
it is a
router or a switch.

It is important in interoperating between boxes that they are each
self-consistent.



The aggregator router could decide not to aggregate routing =
information. 
That way, it can

distribute more specific labels and not worry about inconsistencies =
between the
routes it

has advertised and the labels it distributes.



However, there are reasons why routers aggregate routing information, =
and I
think it may

be difficult to justify why those reasons would not apply equally well =
to label
distribution.



It may very well be the case that routing aggregation is not completely
justified in specific

deployment scenarios. In that case, perhaps it would simply be better to
"turn off" route

aggregation.



--

Eric



Raveendra Torvi wrote:







Eric,

According to your solution  LSPs are broken at the aggregation =
boundary or
IGP area boundary, which may not be desirable in case of all-MPLS =
network. If
main goal is to carry transit traffic by the way of LDP-MPLS switching , =
In
case of all-MPLS networks an operator would like to inject only LDP-FECs =
in
other areas (hence achieve the scalability) or avoid summarization =
LDP-FECs at
IGP area boundary .. Please help me understand. 

Ravi.










On 4/13/06, =
Eric W Gray <ewgray2k@netscape.net> =
wrote:







Bruno,



    No, if anything specific had to be said, it would be =
that Ru
MUST NOT advertise a more

specific FEC to an upstream peer (Ruu in this case) than it has =
advertised in
routing.



    I cannot speak - obviously - for every implementation =
out
there, but here's how I believe

they _should_ work when dealing with an ABR (or other sumarization =
point):



    o   The ABR-LSR advertises summarized =
routes into
an adjacent Area.

    o   The ABR-LSR distributes labels =
corresponding
to those routes to LDP

          peers adjacent to it in =
that same
Area.

    o   The ABR-LSR is then the egress for the
corresponding LSPs,  in those 

          cases where it has =
downstream
routing entries corresponding to more 

          specific routes.

    o   The ABR-LSR MAY - at that point - =
inject
arriving packets on downstream 

          LSPs - after it =
performs a
routing look-up and discovers an FTN (thus

          determing an appropriate =
label and
outgoing interface).



    As I mentioned to Pranjal, this is defined this way =
for
scalability reasons.  It is not the 

intention of MPLS generally to eliminate the need for routing capability =
in the
network at

a cost of introducing unscalably large numbers of label distributions
throughout the same

network.



    Just as an  opinion, a device that is incapable =
of
making this kind of routing decision,

has no business being in a position to summarize routes.



--









Eric













DECRAENE Bruno RD-CORE-ISS =
wrote:






Eric,
 
Thanks for your =
comments.
 
Additional discussions =
inlined.
 
Regards,
Bruno
 
  






-----Original =
Message-----
...[SNIP]...






<>presumably the only thing at issue is =
Ru
should label an IP packet that it receives. =







[Bruno D:] A subsequent issue, is that to =
continue the LSP further
upstream, Ru should allocate a new label and =
advertise the specific FEC
upstream to =
Ruu.
 
  



What will happen is that  the IP packet =
gets sent unlabeled to Rd
which then labels it according to the =
specific route which is the =
best
    =




match
  



to the packet's IP destination =
address.
    =




[Bruno D:] That is indeed the current =
behavior but the problem is =
that
Rd may not be able to forward the IP packet =
(eg Ru is a VPN PE and Rd is
a P). And this may not be an IP packet =
BTW.
 
  



The label imposition procedure here =
is:
 
- get the IP destination =
address
- find  the prefix  in the =
routing  table which  is the best  =
match
    =




(longest
  



  match) for that destination =
address
- use the label  which was assigned to =
that prefix by  the LSR =
which
    =




routing
  



  says is the next hop for that =
prefix.
 
It  doesn't make sense  for =
Rd  to bind  labels to  prefixes =
which
    =




are =
more
  



specific  than  the  one =
in  the  routing  table,  as the  =
label
    =




imposition
=
  



procedure will never make use of such =
labels.
 
I don't think we want to allow  LDP to =
put prefixes in the routing
    =




table, =
or
  



else we'd  have to  treat it =
as  a second  routing algorithm and  =
that
    =




would
  



raise all kinds of =
issues.
    =




[Bruno D:] Such procedure would not change =
the behavior of the IGP and
LDP.
LDP would definitely not act as a routing =
protocol and all routing
decisions (next-hop selection, recheability) =
would still rely on the
 
IGP. LDP would continue advertising labels =
for FECs and would entirely
rely on the RIB for setting up LSPs along the =
IP route.
 
However, as you very correctly pointed out, =
we would allow LDP to
"de-aggregate" the FIB and this may =
raise some issue. However, what =
is
 
the difference, from the FIB point of view, =
between one /30 pointing to
Rd and four /32 pointing to Rd? I believe =
some FIB implementation
already represent a /30 as four =
/32.
 
Besides, if populating the FTN with specific =
FEC is found to be an
 
issue, we can only populate the ILM on all P =
routers. For PE/ingress
router, all we really need is BGP to be aware =
of these LSPs and be able
to use them to reach the BGP Next =
Hops.
 
  



It is possible though to imagine a different =
imposition procedure:
 
- get the IP destination address, =
A
 
- find the prefix, P, in the routing table =
which is the best match
    =




(longest
  



  match) for that destination =
address
 
- get the next hop, N, for P, as specified by =
routing
 
- if N has distributed any label bindings for =
prefixes which are
    =




longer =
than
  



  P but begin with the same sequence =
of  bits as P, and if any =
of
    =




these, =
say
  



  Q, is a better match for A than  =
P, then use the label which N
    =




assigned =
to
  



  =
Q.
 
This is a complicated procedure, =
though.   You can't just match =
A
    =




against =
Q,
  



because there might be some prefix  R in =
the routing table, with a
    =




different
<=
font
size=3D2 color=3Dblack face=3D"Courier New">  



next hop, which is  a better match for A =
than P is, but  not as good =
a
    =




match
  



as Q.  The above imposition =
procedure  says that the next hop for =
the
    =




packet
  



is determined  by the  route =
to  R not  by the route  to P  (or =
Q).
    =




It's =
a
  



complex matter  to keep  the =
forwarding tables  in proper =
shape,
    =




given =
that
  



prefixes like Q can come and go =
asynchronously.
    =




[Bruno D:] I don't think there is a need to =
change the imposition
procedure at all. The modification of the =
label mapping procedure seems
enough. However, as pointing out by Dutta, an =
additional effort is
 
needed to sync LDP with the RIB because as =
you said, more specific
prefixes can come and =
go.
 
 
  



There are other  complications as =
well.  For example, what do  you =
do
    =




if =
you
  



get a packet  which is labeled for =
Q,  but the next hop has  =
changed
    =




and =
the
  



new next hop has not distributed a label for =
Q?
 
I suppose we could figure all this out if =
there were an actual problem
    =




which
  



didn't have a better =
solution.
 
 
 
 
 
 
 
______________________________________________=
_
mpls mailing =
list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
    =




______________________________________________=
_
mpls mailing =
list
mpls@lists.ietf.org
<=
pre>https://www1.ietf.org/mailman/listinfo/mpls
 
 
 
 


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




--
101 Billerica = Ave,
N.Billerica MA -01862

------_=_NextPart_001_01C65F86.85273E8D-- --===============1181172951== 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 --===============1181172951==-- /span>

[Bruno D:] A subsequent issue, is that to =
continue the LSP further
upstream, Ru should allocate a new label and =
advertise the specific FEC
upstream to =
Ruu.
 
  
What will happen is that  the IP packet =
gets sent unlabeled to Rd
which then labels it according to the =
specific route which is the =
best
    =

match
  
to the packet's IP destination =
address.
    =

[Bruno D:] That is indeed the current =
behavior but the problem is =
that
Rd may not be able to forward the IP packet =
(eg Ru is a VPN PE and Rd is
a P). And this may not be an IP packet =
BTW.
 
  
The label imposition procedure here =
is:
 
- get the IP destination =
address
- find  the prefix  in the =
routing  table which  is the best  =
match
    =

(longest
  
  match) for that destination =
address
- use the label  which was assigned to =
that prefix by  the LSR =
which
    =

routing
  
  says is the next hop for that =
prefix.
 
It  doesn't make sense  for =
Rd  to bind  labels to  prefixes =
which
    =

are =
more
  
specific  than  the  one =
in  the  routing  table,  as the  =
label
    =

imposition
=
  
procedure will never make use of such =
labels.
 
I don't think we want to allow  LDP to =
put prefixes in the routing
    =

table, =
or
  
else we'd  have to  treat it =
as  a second  routing algorithm and  =
that
    =

would
  
raise all kinds of =
issues.
    =

[Bruno D:] Such procedure would not change =
the behavior of the IGP and
LDP.
LDP would definitely not act as a routing =
protocol and all routing
decisions (next-hop selection, recheability) =
would still rely on the
 
IGP. LDP would continue advertising labels =
for FECs and would entirely
rely on the RIB for setting up LSPs along the =
IP route.
 
However, as you very correctly pointed out, =
we would allow LDP to
"de-aggregate" the FIB and this may =
raise some issue. However, what =
is
 
the difference, from the FIB point of view, =
between one /30 pointing to
Rd and four /32 pointing to Rd? I believe =
some FIB implementation
already represent a /30 as four =
/32.
 
Besides, if populating the FTN with specific =
FEC is found to be an
 
issue, we can only populate the ILM on all P =
routers. For PE/ingress
router, all we really need is BGP to be aware =
of these LSPs and be able
to use them to reach the BGP Next =
Hops.
 
  
It is possible though to imagine a different =
imposition procedure:
 
- get the IP destination address, =
A
 
- find the prefix, P, in the routing table =
which is the best match
    =

(longest
  
  match) for that destination =
address
 
- get the next hop, N, for P, as specified by =
routing
 
- if N has distributed any label bindings for =
prefixes which are
    =

longer =
than
  
  P but begin with the same sequence =
of  bits as P, and if any =
of
    =

these, =
say
  
  Q, is a better match for A than  =
P, then use the label which N
    =

assigned =
to
  
  =
Q.
 
This is a complicated procedure, =
though.   You can't just match =
A
    =

against =
Q,
  
because there might be some prefix  R in =
the routing table, with a
    =

different
<=
font
size=3D2 color=3Dblack face=3D"Courier New">  
next hop, which is  a better match for A =
than P is, but  not as good =
a
    =

match
  
as Q.  The above imposition =
procedure  says that the next hop for =
the
    =

packet
  
is determined  by the  route =
to  R not  by the route  to P  (or =
Q).
    =

It's =
a
  
complex matter  to keep  the =
forwarding tables  in proper =
shape,
    =

given =
that
  
prefixes like Q can come and go =
asynchronously.
    =

[Bruno D:] I don't think there is a need to =
change the imposition
procedure at all. The modification of the =
label mapping procedure seems
enough. However, as pointing out by Dutta, an =
additional effort is
 
needed to sync LDP with the RIB because as =
you said, more specific
prefixes can come and =
go.
 
 
  
There are other  complications as =
well.  For example, what do  you =
do
    =

if =
you
  
get a packet  which is labeled for =
Q,  but the next hop has  =
changed
    =

and =
the
  
new next hop has not distributed a label for =
Q?
 
I suppose we could figure all this out if =
there were an actual problem
    =

which
  
didn't have a better =
solution.
 
 
 
 
 
 
 
______________________________________________=
_
mpls mailing =
list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
    =

______________________________________________=
_
mpls mailing =
list
mpls@lists.ietf.org
<= pre>https://www1.ietf.org/mailman/listinfo/mpls
 
 
 
 


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




--
101 Billerica = Ave,
N.Billerica MA -01862

------_=_NextPart_001_01C65F86.85273E8D-- --===============1181172951== 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 --===============1181172951==-- From mpls-bounces@lists.ietf.org Mon Apr 17 17:17:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVb4E-0000UR-Ey; Mon, 17 Apr 2006 17:15:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVb4C-0000UM-BP for mpls@ietf.org; Mon, 17 Apr 2006 17:15:28 -0400 Received: from imo-d02.mx.aol.com ([205.188.157.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVb4C-0005ql-1K for mpls@ietf.org; Mon, 17 Apr 2006 17:15:28 -0400 Received: from ewgray2k@netscape.net by imo-d02.mx.aol.com (mail_out_v38_r7.5.) id c.e9.14dde19d (22683); Mon, 17 Apr 2006 17:15:23 -0400 (EDT) Received: from [192.168.3.101] (c-24-128-207-21.hsd1.nh.comcast.net [24.128.207.21]) by air-in04.mx.aol.com (v108_r3.6) with ESMTP id MAILININ44-589b4444056a2bd; Mon, 17 Apr 2006 17:15:22 -0400 Message-ID: <444405CA.1040501@netscape.net> Date: Mon, 17 Apr 2006 17:16:58 -0400 From: Eric W Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: erosen@cisco.com Subject: Re: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs References: <200604141651.k3EGpjTL002085@rtp-core-1.cisco.com> In-Reply-To: <200604141651.k3EGpjTL002085@rtp-core-1.cisco.com> X-AOL-IP: 24.128.207.21 X-Mailer: Unknown (No Version) X-Spam-Flag: NO X-Spam-Score: 0.6 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: DECRAENE Bruno RD-CORE-ISS , mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@GraIyMage.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0215030402==" Errors-To: mpls-bounces@lists.ietf.org --===============0215030402== Content-Type: multipart/alternative; boundary="------------040503090404090406060409" --------------040503090404090406060409 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I think Eric Rosen sums this up nicely. -- Eric Gray Eric Rosen wrote: >>In Downstream Unsolicited label advertisement mode, Ru does >>not know what Ruu wants or needs. Ru always propagates the FEC upstream >>and Ruu uses it if needed. >> >> > >So once some node decides to do this "LDP de-summarization", there's no way >to stop it until you reach the border of the MPLS domain? I think we'd >probably end up with a bunch of configuration knobs controlling LDP >desummarization, similar to the knobs controlling IGP summarization. > > > >>there is no change compared to using RFC 3036 and performing route leaking >>on ABR. In both cases, in the FIB, you have an aggregated prefix and more >>specific ones. >> >> > >I didn't say that your proposal adds more prefixes to the FIB than it would >have if the the /32s were carried by OSPF. I said that the management of >the forwarding table is made more complicated, because we now have entries >which are jointly managed by two different protocols which have a complex >relationship with each other. > > > >>instead of advertising the specific prefixes once in the IGP and once in >>the LDP, we would only advertise it once >> >> > >I don't think this is a meaningful comparison. LDP does not currently >advertise prefixes, it advertises label bindings. In your proposal, new >functionality is added so that LDP does advertise prefixes. Thus the number >of "prefix advertisements" stays the same. You're merely shifting some of >the prefix advertisement burden from one protocol to the other. And the >work of managing those prefixes in the forwarding table is more >complicated. All that really gets saved is the work required to parse the >OSPF messages. > >I guess my problem is that I see the additional complexity, but I don't see >the data showing that, as a result of adding this complexity, we gain a big >improvement in the number of /32s to which we can assign labels. I also >don't see that this is yields a better set of tradeoffs than a hierarchical >soltuion. > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/mpls > > > > > --------------040503090404090406060409 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I think Eric Rosen sums this up nicely.

--
Eric Gray

Eric Rosen wrote: 
In Downstream Unsolicited label advertisement mode, Ru does
not know what Ruu wants or needs. Ru always propagates the FEC upstream
and Ruu uses it if needed. 
    

So once some node decides to  do this "LDP de-summarization", there's no way
to stop  it until you  reach the  border of the  MPLS domain?  I  think we'd
probably  end  up  with  a  bunch of  configuration  knobs  controlling  LDP
desummarization, similar to the knobs controlling IGP summarization. 

  
there is no change compared to using RFC 3036 and performing route leaking
on ABR. In both cases, in the  FIB, you have an aggregated prefix and more
specific ones. 
    

I didn't say that your proposal adds  more prefixes to the FIB than it would
have if the  the /32s were carried  by OSPF.  I said that  the management of
the forwarding table  is made more complicated, because  we now have entries
which are  jointly managed by two  different protocols which  have a complex
relationship with each other.

  
instead of advertising  the specific prefixes once in the  IGP and once in
the LDP, we would only advertise it once
    

I  don't think  this is  a meaningful  comparison.  LDP  does  not currently
advertise  prefixes, it advertises  label bindings.   In your  proposal, new
functionality is added so that LDP does advertise prefixes.  Thus the number
of "prefix advertisements"  stays the same.  You're merely  shifting some of
the prefix  advertisement burden  from one protocol  to the other.   And the
work  of   managing  those  prefixes   in  the  forwarding  table   is  more
complicated. All  that really gets saved  is the work required  to parse the
OSPF messages.

I guess my problem is that I  see the additional complexity, but I don't see
the data showing that, as a result  of adding this complexity, we gain a big
improvement in  the number of  /32s to which  we can assign labels.   I also
don't see that this is yields  a better set of tradeoffs than a hierarchical
soltuion. 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
--------------040503090404090406060409-- --===============0215030402== 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 --===============0215030402==-- From mpls-bounces@lists.ietf.org Tue Apr 18 04:04:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVlAX-0001jw-5C; Tue, 18 Apr 2006 04:02:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVlAW-0001jo-4y for mpls@ietf.org; Tue, 18 Apr 2006 04:02:40 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=oberon.imc.kth.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVlAU-0005Y5-MV for mpls@ietf.org; Tue, 18 Apr 2006 04:02:40 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id k3I7qR7u014103 for ; Tue, 18 Apr 2006 09:52:28 +0200 Received: from [127.0.0.1] ([172.16.2.224]) by mail1.imc.kth.se; Tue, 18 Apr 2006 10:01:40 +0200 Message-ID: <44449CE2.8040104@pi.se> Date: Tue, 18 Apr 2006 10:01:38 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org, ccamp Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: [mpls] mpls wg comments on T-MPLS - schedule 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: , Errors-To: mpls-bounces@lists.ietf.org Working Group(s), (after agreement with the ccamp co-chairs this is sent to the ccamp list also) after discussion with representatives for SG15 and Q12/15 we've some tentative procedure to get our comments on Transport-MPLS into the ITU process. EoB today (Tuesday April 18th) we will give them a list of areas where we have concerns (copy to the mpls mailing list). "End of Business day" will be understood as 11.59PM here in Stockholm (corresponds to approx. 6PM in Boston). We will abstract the list from comments sent to the mpls mailling list. On Friday (April 21st) we will send them a more consolidated list, they have a meeting in Kobe the following week. However, the formal working group comments will be sent to them May 17th. Please send (furthher) comments on G.8110.1 (https://datatracker.ietf.org/documents/LIAISON/file288.zip) G.8112 (https://datatracker.ietf.org/documents/LIAISON/file289.zip) G.8121 (https://datatracker.ietf.org/documents/LIAISON/file290.zip) to the mpls working group mailing list. /Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 18 18:33:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVyiv-0002HY-F6; Tue, 18 Apr 2006 18:31:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVyiu-0002HT-Dd for mpls@ietf.org; Tue, 18 Apr 2006 18:31:04 -0400 Received: from pne-smtpout2-sn1.fre.skanova.net ([81.228.11.159]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVyir-0001pA-Tq for mpls@ietf.org; Tue, 18 Apr 2006 18:31:04 -0400 Received: from [127.0.0.1] (213.66.236.118) by pne-smtpout2-sn1.fre.skanova.net (7.2.070) id 4444940C00040A6F; Wed, 19 Apr 2006 00:31:00 +0200 Message-ID: <444568A3.9010408@pi.se> Date: Wed, 19 Apr 2006 00:30:59 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: multipart/mixed; boundary="------------090701010107040502090502" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: Subject: [mpls] list of concerns on T-MPLS 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: , Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --------------090701010107040502090502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, this is the very preliminary information we sent to Q12/15 on T-MPLS. The intention is to consolidate it further during this week. Comments appreciated. Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se --------------090701010107040502090502 Content-Type: text/plain; name="list-of-concerns.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="list-of-concerns.txt" Areas of concerns on Transport MPLS from the MPLS working group =============================================================== To: Q12/15 At this point, members of the IETF are expressing their concerns on Transport-MPLS on the MPLS and CCAMP mailing lists. We are working to collect and evaluate these and come to a consensus response to your liaison. The list included here is preliminary. For the next version issues might be added or cleared. However we would like to alert you that our preliminary judgment is that some of the issues are of a serious nature. Requirements ------------ We have not seen any requirements specification for T-MPLS. Penultimate Hop Popping (PHP) ----------------------------- We discussed this several times with different ITU-T SGs and Questions, we've agreed that the right way of stating this is that it is "mandatory to implement, optional to use" PHP. We would appreciate if the T-MPLS could adopt the same text. Note: We also think that it is a misconception to think that non-PHP is less complex than PHP. Signaling protocol ------------------ It is nowhere specified which signaling protocol will be used for for T-MPLS. It is also unclear if traffic engineering functionality is required. Note: if traffic engineering functionality is required, there is a strong recommendation from the IETF to use RSVP-TE. Non-merging ----------- T-MPLS states that merging of LSPs is not used. Merging was introduced to address the problem with a high number of LSPs in the core. How is the n-squared problem addressed in T-MPLS? Note that it is not a given that non-merging of LSPs is from a protocol procedural or processing point of view necessarily less complex than a merging variant. Reserved labels --------------- MPLS reserves label values 0-15 for special use. T-MPLS at one point also intended to reserve values 16-31 for similar use. It has been pointed out that this will make all existing MPLS implementations incompatible with T-MPLS. Labels 16-31 is said to be for further study. Some comments to the MPLS mailing list indicates that there is no plans to assign any semantics to labels 16-31. What is the reason to mention them if this is the case. True subset of MPLS ------------------- It has been claimed that T-MPLS is a true subset of MPLS, yet the Y.1711 seems to be a part of T-MPLS. Y.1711 is not part of MPLS. If what is wanted is really a subset of MPLS, we believe several aspects has to be made clear - the exact relationship to MPLS - that enough functionality is there to make it interoperable with MPLS - the MPLS OAM specification in RFC4377 has to be addressed There is previous art in defining similar "subsets" of MPLS, e.g. "draft-loa-mpls-cap-set-01.txt" and "draft-rosen-mpls-profiles-00.txt"; these efforts did not go very far since it was not obvious that they solved a real problem. T-MPLS trademark ---------------- It has been brought to our notice that one of the parties active in developing the T-MPLS has a trademark on "T-MPLS". We don't know if this is a serious matter. Interoperability at the MPLS / T-MPLS interface ----------------------------------------------- Several of the issues we have are for the interoperability between a T-MPLS device and an MPLS device. We can't see that these issues are discussed anywhere. Per platform or per interface labels +++++++++++++++++++++++++++++++++++ For a local link repair it is crucial whether the box you are talking to uses a per platform or per link label space. Global labels +++++++++++++ T-MPLS renames per platform labels "global labels", since this it a term used for to signify domain wide labels. T-MPLS should align with the MPLS terminology. TTL management and LSP tunnels ++++++++++++++++++++++++++++++ RFC3443 describes how TTLs are handled in LSPs tunnels. The G.8110.1 state that it only supports RFC3443 for pipes and short pipes only. This is a potential incompatibility with MPLS over the interface between MPLS and T-MPLS networks. Interoperability over interface between MPLS and T-MPLS networks ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Some of the MPLS applications has been designed with MPLS features taken for granted, e.g.: - pseudowires assumes per platform labels - VPN assumes PHP - etc for these applications to work as before a T-MPLS box will need to have to types of interfaces. One interface that works as specified in T-MPLS and another interface that works as specified in MPLS. The T-MPLS needs to translate between the T-MPLS and the MPLS environment since this is not in the MPLS specifications from start. --------------090701010107040502090502 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 --------------090701010107040502090502-- From mpls-bounces@lists.ietf.org Thu Apr 20 02:43:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWSqy-0003Nq-AF; Thu, 20 Apr 2006 02:41:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWSqw-0003Ni-6j for mpls@ietf.org; Thu, 20 Apr 2006 02:41:22 -0400 Received: from [213.187.112.132] (helo=[213.187.112.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWSqv-0003TQ-Aq for mpls@ietf.org; Thu, 20 Apr 2006 02:41:22 -0400 Date: Thu, 20 Apr 2006 6:41:22 -0180 From: "Dana Clemons" X-Mailer: The Bat! (v3.0.1.33) CD5BF9353B3B7091 X-Priority: 3 (Normal) Message-ID: <668477706.20060420064122@cisco.com> To: mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [mpls] Dont invest before you read X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dana Clemons List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Radar Alert. Add SIKY to your radars and watch like a hawk. Major Pr Campaign starting right now! Do not take your eyes of SIKY! THE COMPANY Sticky Web, Inc.’s (SIKY:PINKSHEETS) an intellectual property company with key Internet, software and business method patents in e-mail, e-commerce, internet software and technologies. The first patent “METHOD FOR MANAGING BULK E-MAIL DISTRIBUTION”, patent number 6,631,400, was issued by the USPTO on October 7, 2003. The second patent "METHOD FOR DEVELOPING ELECTRONIC DOCUMENTS EMPLOYING MULTIPLE DISPLAY REGIONS", patent number 6,771,291, was issued by the USPTO on August 3, 2004. There are six patents issued and pending. $10B MARKETPLACE FOR ISSUED PATENTS The 6,631,400 and 6,771,291 patents cover industries with over $10B in annual revenue. The e-mail patent, number 6,631,400, represents a whole industry with approximately $10 billion in worldwide annual revenue that protects the logical steps in e-mail management and distribution. Patent no. 6,771,291 protects the way people interact with and create electronic documents by using multiple screens or windows. RECENT HISTORY OF PATENT ENFORCEMENT (Are they trying to tell us something?) The recent settlement between NTP vs. RIM-BlackBerry® (RIMM.NASDAQ) and Burst Technology, Inc. (BRST.PK), and the ongoing battle with Eolas Technologies, Inc. vs. Microsoft (MSFT.NASDAQ) has leveled the playing field allowing the small inventors the same patent licensing benefits that large corporations have always enjoyed. $450M-RIM/BlackBerry® and NTP. Inventor NTP settles for $450M. $521M-EolasTechnologies/Microsoft. Inventor Eolas wins judgment for $521 M, Microsoft continues to appeal. $60-Burst.com/Microsoft - Inventor Burst settles for $60M. These three patent enforcement actions and settlements typify those that have been successfully brought by the individual inventor and small business against industry leaders. Is SIKY ready to enforce their patents too? This could be a great watch! Keep a keen eye out for upcoming news! Information within this report contains forward looking statements within the meaning of Section 27A of the Securities Act of 1933 and Section 21B of the SEC Act of 1934. Statements that involve discussions with respect to projections of future events are not statements of historical fact and may be forward looking statements. Don't rely on them to make a decision. The Company is not a reporting company registered under the Exchange Act of 1934. We have received three hundred fifty six thousand free trading shares from a third party not an officer, director or affiliate shareholder. We intend to sell all our shares now, which could cause the stock to go down, resulting in losses for you. This company has: an accumulated deficit, a negative net worth, nominal cash and no revenues in its most recent quarter. It is an operating company. The company is going to need financing to continue as a going concern. A failure to finance could cause the company to go out of business. Read the Company's Annual Report and Information Statement before you invest. This report shall not be construed as any kind of investment advice or solicitation. You can lose all your money by investing in this stock. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Apr 20 06:46:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWWe0-0007XI-SH; Thu, 20 Apr 2006 06:44:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWWdy-0007XD-V4 for mpls@ietf.org; Thu, 20 Apr 2006 06:44:14 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWWdx-0007GW-O4 for mpls@ietf.org; Thu, 20 Apr 2006 06:44:14 -0400 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k3KAiCqE004515; Thu, 20 Apr 2006 05:44:12 -0500 (CDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 20 Apr 2006 06:44:00 -0400 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'Loa Andersson'" , mpls@ietf.org Subject: RE: [mpls] list of concerns on T-MPLS Date: Thu, 20 Apr 2006 06:43:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Loa, Two questions about the end of the document: TTL Management: What exactly is the concern? Is it that the operator would set a TTL value assuming that the uniform model is used, while in fact the T-MPLS core uses the pipe model and does not decrease the TTL value in the way the operator expected? If so, is it realistic to assume that the operator would not be aware of this? Interoperability over interface between MPLS and T-MPLS networks: are we merely pointing out that the T-MPLS spec should address these issues, or is there a really concern that this will not work? E.g. PWs use per-platform labels because of potential PHP. However, I don't see how not using PHP would invalidate the existing PW specs. Same comment for VPNs. Am I missing something? Peter > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: Tuesday, April 18, 2006 6:31 PM > To: mpls@ietf.org > Subject: [mpls] list of concerns on T-MPLS > > > All, > > this is the very preliminary information we sent to Q12/15 on > T-MPLS. The intention is to consolidate it further during this > week. > > Comments appreciated. > > Loa and George > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Apr 21 05:13:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWrf0-0007Pk-2V; Fri, 21 Apr 2006 05:10:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWrey-0007Pf-DA for mpls@ietf.org; Fri, 21 Apr 2006 05:10:40 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=oberon.imc.kth.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWrew-0001t6-Vv for mpls@ietf.org; Fri, 21 Apr 2006 05:10:40 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id k3L90DoI031633 for ; Fri, 21 Apr 2006 11:00:14 +0200 Received: from [127.0.0.1] ([172.16.2.224]) by mail1.imc.kth.se; Fri, 21 Apr 2006 11:09:29 +0200 Message-ID: <4448A144.4010405@pi.se> Date: Fri, 21 Apr 2006 11:09:24 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [mpls] wg last call on draft-ietf-mpls-p2mp-oam-reqs-01 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: , Errors-To: mpls-bounces@lists.ietf.org All, this mail initiates a two week working group last call on draft-ietf-mpls-p2mp-oam-reqs-01.txt Please send comments to the working group mailing list and/or the working group chairs. This wg last call ends EoB May 5 2006. Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Apr 21 09:31:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWvgj-0008WB-Mb; Fri, 21 Apr 2006 09:28:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWvgi-0008W6-Em for mpls@ietf.org; Fri, 21 Apr 2006 09:28:44 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=oberon.imc.kth.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWvgh-0007YK-9X for mpls@ietf.org; Fri, 21 Apr 2006 09:28:44 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id k3LDILsd011771 for ; Fri, 21 Apr 2006 15:18:22 +0200 Received: from [127.0.0.1] ([172.16.2.224]) by mail1.imc.kth.se; Fri, 21 Apr 2006 15:27:35 +0200 Message-ID: <4448DDC5.90202@pi.se> Date: Fri, 21 Apr 2006 15:27:33 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: multipart/mixed; boundary="------------020507090609080807000402" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b21264b25b2584da3ddf2bd579ca48f Cc: Subject: [mpls] updated wg minutes from Dallas 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: , Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --------------020507090609080807000402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Working Group, I've uopdated the minutes according to comments. At least the comments I've seen. The IETF schedule require me to upload the minutes toady. If you have further comments send them asap. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se --------------020507090609080807000402 Content-Type: text/plain; name="mpls-minutes-dallas.txt" Content-Disposition: inline; filename="mpls-minutes-dallas.txt" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by oberon.imc.kth.se id k3LDILsd011771 Minutes form MPLS WG meeting at the IEYF65 in Dallas =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Monday, March 20, 2006, 9.00 - 11.30 AM 1. Agenda bashing ----------------- Agenda adopted as presented. 2. Working group status ----------------------- As of this meeting we have a new Area Director for the Routing Area,=20 Ross Callon. We welcome Ross and thanks Alex for the last for four=20 years. A good MPLS status page could be found at: http://www1.tools.ietf.org/wg/mpls/ apart from document status it is possible to find also agendas and=20 There are five new RFCs since the last meeting: RFC 4379 (LSP ping) RFC 4378 (OAM Framwork) RFC 4377 (OAM Requirements) RFC 4220 (TE Link MIB) RFC 4221 (Management Overview) =20 There is also a non working group RFC: RFC 4381 (Informational) Title: Analysis of the Security of=20 BGP/MPLS IP Virtual Private Networks (VPNs) M. Behringer that should be interesting reading for the working group. The following documents are the in RFC-ed Queue: ------------------------------------------------ - draft-ietf-mpls-bgp-mpls-restart-05, for this draft there is a=20 dependency to a document in the Inter Domain Routing (idr) working group. - draft-ietf-mpls-p2mp-sig-requirement-04, for this draft there is=20 no obvious unresolved issues, and it should be published soon. The following documents are in IESG review: ------------------------------------------ The three drafts in the package to take LDP to Draft Standards: - draft-ietf-mpls-ldp-experience-00.txt - draft-ietf-mpls-ldp-survey2002-00.txt - draft-ietf-mpls-rfc3036bis-03.txt --------------------------------------- Alex reported from the IESG review. There are issues in that the=20 IETF Standards Process (RFC 2999) says that a normative reference in a Draft Standard can't point to a document that is "only" a Proposed=20 Standard. The LDP specification is dependent on the MPLS=20 Architecture (RFC 3031) that is still Proposed Standard. The suggested remedy here is to included enough of the of the=20 information that is reference directly in the LDP specification and then move the reference to Informational. Eric R said that this is a dumb idea. If you put pieces of one=20 specification in another then you are creating problems Alex - we're not cut and pasting. For example if we look at place=20 where label is distributed in LDP will treat this as an unsigned=20 integer and then ref to the other doc. Eric pointed out that the standards process is broken if it can't handle this situation and if it is this broken we should revisit=20 the decision to make LDP a Draft Standard, and just republish it as a Proposed Standard. If we put pieces (however small) into=20 orther specifications we create a even more complicated than the one we have today, how to we update and change status on documents. The leason we've learnt is that the broken process generates lots=20 of useless work. Alex said that we have a general problem with normative references that needs to be fixed, this is not limited to MPLS docs, it the IETF can't manage this we'll find ourselves in the situation we were 5-6 years ago where MPLS docs were in the RFC-Iditors queue for=20 years as none of them could go ahead beacuse of very "meshy"=20 references. We need to find a way to decouple references. =20 - draft-ietf-mpls-ecmp-bcp-02.txt --------------------------------- This draft is also in IESG evaluation. There is a "discuss" in the=20 review that has not been solved. George will meet with Margaret=20 Wasserman to try to solve the problem this week. As soon as the=20 discuss is resovled a new draft with be published, - draft-ietf-mpls-nodeid-subobject-07.txt ----------------------------------------- This document has been approved by the IESG and announced, but has=20 not yet shown up in the RFC-Editors queue. Working group drafts: --------------------- The draft that will be on the agenda later is not reiterated here. =09 draft-ietf-mpls-icmp-04 ----------------------- This drafts has a dependency on a draft progressed in the Internet Area, that draft will be on the Internet Area agenda this week. Ron will be back with further information as soon as we have the outcome of the discussion in Internet Area. draft-ietf-mpls-lsr-self-test-06 -------------------------------- The LSP Ping has been approved, so the LSR Self Test is now ready=20 to be sent to the IESG for review. draft-ietf-mpls-multicast-encaps-00 ----------------------------------- No news this time draft-ietf-mpls-over-l2tpv3-01 ------------------------------ The draft has been republished and is ready for Working Group Last=20 call. draft-ietf-mpls-p2mp-lsp-ping-00 -------------------------------- This draft has been waiting on multicast LDP to stabilize. The issue has been whether to put TE and LDP in the same draft or not. Authors want to discuss with the multicast LDP authors during this week to reach an agreement. draft-ietf-mpls-p2mp-oam-reqs-01 -------------------------------- There were useful comments on list on the earlier draft, it has been respun. The authors think it is ready for working last call. draft-ietf-mpls-soft-preemption-07 ---------------------------------- This draft has a dependency on a yet unpublished BCP, J-P has=20 promised to start the process to get this BCP moving. draft-ietf-mpls-upstream-label-00 ---------------------------------=09 No news. "Un-published" working group drafts ---------------------------------- draft-raggarwa-mpls-ldp-upstream-00 has been accepted as a=20 working group draft and will be published after the IETF meeting. Other than that - no news. "Dated draft" working group drafts ---------------------------------- draft-ietf-mpls-fastreroute-mib-04 has expired, Tom has taken the initiative to republish and finalize this draft. 3. MPLS traffic engineering --------------------------- draft-vasseur-mpls-number-0-bw-te-lsps-00 ----------------------------------------- The problem addressed in this draft is balancing trafffic across=20 multiple ECMPs. Currently non-zero b/w LSPs balance OK the 0 b/w=20 ones don't. To re-optimise one need to know how many 0 b/w LSPs one have per link. Currently there is no knowledge of this in OSPF-TE or ISIS-TE so one can't just run a CSPF. Proposal is a new sub-TLV that just advertises the number of=20 zero-b/w LSPs on each link. There is no changes in the flooding procedure involved and no IGP=20 scaling impact. This is a very simple solution, to a very real=20 problem. Working group chairs pointed out that this proposes changes to OSPF and ISIS. It should be taken to those WGs after we agreed that it is=20 a requirement? draft-ietf-mpls-explicit-resource-control-bundle-01 --------------------------------------------------- No one of the authors were present. This item was deferred. draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01 ------------------------------------------------- Kohei Shiomoto This draft is intended for the CCAMP working group presented here for information and to solicit feedback.=20 The draft discusses migration requirements, models, and scenarios for a migration from an MPLS-TE to an GMPLS control plane. For the migration period four interworking scenarios has been identified: 1) MPLS->GMPLS->MPLS 2) GMPLS->MPLS-GMPLS 3) GMPLS->MPLS 4) MPLS->GMPLS In the first two cases the ingress and egress LSRs are in the same technology domain. There are two major areas that need more work - signalling and=20 routing. To achieve the migration goal we need to pay special=20 attention to differences how these are treated in the MPLS and GMPLS domain. The problems are mostly identified and the next step is to is to figure out which solution directions we should take. =20 Feedback and comments from the MPLS working group is appreciated. draft-yasukawa-mpls-scaling-analysis-00 draft-yasukawa-mpls-mp2p-rsvpte-00 --------------------------------------- Seisho The drafts discusses MPLS scaling issues given larger MPLS P2P=20 networks, if a large number of PEs need to be fully meshed this generates a huge number of LSPs in the core. The draft looks at=20 different scaling limitations, e.g. memory, processing and=20 management. Memory is not seen as a real problem, the processing issues might be for e.g. soft-state, protocols, the impact of a large number of=20 LSPs on Network Management Systems (NMS) could be drastic. The draft discusses three possible strategies to address these scaling issues, P2P tunnels in the core, LSP hierarchy and MP2P LSPs. P2P tunnels gives god scaling in the core, LSP hierarchy is most=20 effective towards the edge, while MP2P LSPs is effective near the=20 egress, but have no impact near the ingress. Next step will be continued analysis of scaling issues, to determine real network sizes and limitations. A requirements draft will be=20 written, and work with implementers is planned. JP commented that this is very interesting and promising as far as it goes. However there are issus that in to be addressed. These=20 issues are e.g. sizing of core tunnels, fast re-route and protection of hierachical LSps will reduce the benefits. JP offered to work=20 with the authors to cover these issues. This draft is intended to become an Informational RFC. 4. MPLS p2MP ------------ P2MP LDP requirements draft-leroux-mpls-mp-ldp-reqs-03 -------------------------------- Jean-Louis Changes since previous version - solution oriented requirements and=20 text that said that a multicast routing prtocol should not be=20 required been removed. A "complexity requirement" has been added saying that additional=20 routing protocol should not be required in the core. Requirements on avoiding replication on LAN interfaces has been=20 clarified. A branch LSR must be able to send one copy on a LAN to=20 reach multiple downstream LSRs. It must be possible to select a=20 single upstream LSR on a LAN for one P2MP LSP and it shall be=20 possible to load balance between candidate upstream LSRs. The draft is now quite stable, but needs working group feedback.=20 There are some comments (mostly editorial) that will be included in the next version.=20 There is a growing support to make this a working group document, working group chairs will take this to the mailing list. draft-ietf-mpls-ldp-p2mp-00 --------------------------- Ice This draft is the outcome of merging to earlier drafts from Ina and Ice. It is now a working group document. Changes since the earlier individual version - references to the=20 upstream label allocation drafts has been added. =20 There is some future work needed: - resolve issues of ECMP upstream LSR selection - minimize packet loss during upstream LSR change=20 (make before break?) draft-ietf-mpls-rsvp-te-p2mp-03 ------------------------------- Dimitri Some point has been discussed over the last couple of weeks, it is time to wrap up. - document how to protect against branch failure, there are three=20 alternatives a. include the simple cases in the current draft and leave the rest to another draft b. take the whole issue to a separate draft c. postpone publication until we have solved this issue No one is arguing for option c, and we seems to be converging on=20 option b. There is also a proposed a clean-up of the terminology. Version 4 will be ready to publish end of April and should be the draft we take to working group last call. Reroute Extensions to LDP for P2MP LSP draft-liu-mpls-ldp-p2mp-reroute-00.txt -------------------------------------- Shuying Liu The goal of this draft is to reduce disruption and duplication during rerouting. The rerouting mechanism in draft-ietf-mpls-ldp-p2mp has issues in terms of LSR load, traffic disruption and scaling. A new mechanism which reduces disruption time and data duplication is proposed. Working group chairs pointed out that there is already a working group document that potentially will address these issues (draft-ietf-mpls-ldp-p2mp-00). The two group a=F3f authors should discuss and see if it is possible to merge these ideas into the working group documents. 7. T-MPLS; report from the IETF liaison to ITU-T SG15 ----------------------------------------------------- Transport MPLS Adrian Adrian very carefully pointed out that he was reporting on an=20 activity within the ITU-T Q12/15 for information.=20 "Don't shot the messenger". He also did a quick ITU-T introduction and discussed the relevant Study Groups (SG). ITU-T is very contribution and process driven. SG-13 is NGN, SG-15 is access network transport and optical=20 techologies. T-MPLS is not optical, but it is access network transport. Question 12 in SG-15 (Q12/15) owns T-MPLS. A Question is the ITU-T=20 rough equivalent to an IETF working group. The T-MPLS activity has been going more than a year. But so far no information on this has been sent to IETF and/or the MPLS working group. ITU-T and Q12/15 have consented recommendations (roughly equvialent to and RFC) for an T-MPLS architecture (G.8110.1 - Feb 06) and Interfraces for T-mPLS hierarchy (G8112). The T-MPLS is build on MPLS, but it is not obvious that it is=20 directly compatible. It introduces a formal structure (e.g. UNI and NNI), some functional restrictions as compared to MPLS (e.g. no=20 PHP, no MP2P/LDP, no ECMP). All LSPs are uni-directional,=20 bi-directional LSPs are created by associating two uni-diretional LSPs, i.e. not GMPLS compatible. OAM are according to Y.1711, i.e. not compatible with LSP ping. =20 Protection switching and survivability is Y.1720. =20 P2MP is for furhter study. The control plane is not decided, but ASON, MPLS-TE, GMPLS, LDP++ are still discussed, though it is not clear what LDP++ really is. Anyway it is an indication that the LDP base specification is not sufficient. One criticial issue from an MPLS point of view is that labels 16-31=20 have been chopped out as reserved lables for future study. If this happens all existing MPLS HW will be incompatible with T-MPLS. =20 Next steps: 1) get a copy (limited free download allowed and MLPS WG may liase=20 to ITU-T to get a copy). 2) debate (with care!) Remember these are from another body with=20 their own views and they have put *serious* thought into it. =20 therefore raise Qs, don't tell ITU-T what to do. 3) show (somehow) that existing protocols meet the needs (if they=20 do). Eric R: This might be one of the few cases where it may be=20 appropriate to shoot the messenger! =20 IETF doesn't want to get involved in this attempt to do Frame-based ATM. It would be best not to engage at all. It would be useful=20 to figure out whether T-MPLS is incompatible with MPLS in data=20 plane, and if so then send a liason to ITU-T asking them to make=20 it clear that T-MPLS is not MPLS. Adrian pointed out that if ITU-T Q12/15 or anone else decide to=20 extend or tweak our protocols then we need to either be involved or=20 to let them do it.=20 Loa: In the particular case of ITU-T there is an agreement between them and IETF to exchange certain type of information. Q12/15 has=20 failed to do this in this case. Dimirti - we already have several flavours of control plane,=20 we don't want another. Kireeti - It is very annoying that this has even got this far.=20 We have a GMPLS/MPLS change process. The idea was to do this=20 co-operatively with ITU-T people. Now they've got a set of=20 requirements that became a recommendation without working with=20 the proper IETF Working Groups. Mandating no PHP is funky,=20 mandating no merging is really funky. Can't just go round messing with SIP and call it SIP. So can't go messing with MPLS and call=20 it MPLS. Yakov - it is interesting that thee same discussion can say=20 "no merging" and "LDP" (which is MP2P protocol). Italo (Editor of G.8110.1) - we are willing to discuss. T-MPLS is defined to be a sub-set of MPLS. Idea was not to deviate from the current standard. George - as chair you need either to liase with us (if you want=20 to use the name "MPLS") or go off and name/do your own thing... =20 if it's called "T-MPLS" then its name is a little close to MPLS=20 so it would be nice to agree with us. Is "consented" final? Editor - no, you can do last call comments after consented. =20 Last call is end of this month. Yakov - Question to WG and its chair. If you take the MPLS data=20 plane as is and use PNNI as the control plane then what would you call it? Answering that question will help us deal with this Q. George - "We could do that, but that would be wrong". Loa - The working group chairs will send a liaison to SG15 and point out the failure to communicate and require that the T-MPLS documents are liaised to the MPLS working group. 8. RSVP-TE extensions --------------------- draft-xu-mpls-rsvp-te-bidirection-00 ------------------------------------ Xiaohu Xu By the binding of two unidirectional RSVP-TE tunnels between a pair of LSRs, a bidirectional RSVP-E tunnel could be formed. The=20 bidirectional RSVP-TE tunnel can be used e.g. to establish L3VPN=20 with virtual router technology. =20 It was decided to take this discussion to the working group mailing- list. 9. End of meeting --------------020507090609080807000402 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 --------------020507090609080807000402-- From mpls-bounces@lists.ietf.org Fri Apr 21 12:40:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWycg-0005vF-2A; Fri, 21 Apr 2006 12:36:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWyce-0005v9-L5 for mpls@ietf.org; Fri, 21 Apr 2006 12:36:44 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=oberon.imc.kth.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWycd-0001Kj-6R for mpls@ietf.org; Fri, 21 Apr 2006 12:36:44 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id k3LGQHJF021250 for ; Fri, 21 Apr 2006 18:26:21 +0200 Received: from [127.0.0.1] ([172.16.2.224]) by mail1.imc.kth.se; Fri, 21 Apr 2006 18:35:24 +0200 Message-ID: <444909C9.2070106@pi.se> Date: Fri, 21 Apr 2006 18:35:21 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [mpls] working group document candidates 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: , Errors-To: mpls-bounces@lists.ietf.org All, the authors of the two following drafts has requested that they are adopted as working group documents: draft-vasseur-mpls-number-0-bw-te-lsps-00 draft-leroux-mpls-mp-ldp-reqs-03.txt draft-vasseur-... was discussed at the mpls wg meeting in Dallas. We had a good support for the general idea, but were uncertain how this should be handled document-wise. The normal work flow would be that the mpls wg write a requirement draft to the ospf and is-is working groups, who each produce one spec for the extension for their protocols. It has however been argued that this could be addres in a single draft of less than a handful pages. The (is-is, ospf and mpls) working group chairs and the routing area ADs have there fore agreed that we can do it in a single mpls working group document, which will be sent to the other two working groups for review. draft-leroux-... was discussed at the same meeting, and there were a good support in the room for adopting it as a working group document. Please respond to the mailing list whether you think they should become wg docs or not. Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Apr 21 12:51:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWyoN-0007d1-Az; Fri, 21 Apr 2006 12:48:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWyoL-0007cw-79 for mpls@ietf.org; Fri, 21 Apr 2006 12:48:49 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWyoJ-0001p9-Ux for mpls@ietf.org; Fri, 21 Apr 2006 12:48:49 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 21 Apr 2006 09:48:47 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,145,1144047600"; d="scan'208"; a="26393592:sNHT23488432" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3LGmlTL023149; Fri, 21 Apr 2006 12:48:47 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Apr 2006 12:48:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] working group document candidates Date: Fri, 21 Apr 2006 12:48:46 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] working group document candidates Thread-Index: AcZlYgiEUaUVWjAXRKOVdyfShNdGQQAATYgg From: "Zafar Ali \(zali\)" To: "Loa Andersson" , X-OriginalArrivalTime: 21 Apr 2006 16:48:47.0028 (UTC) FILETIME=[75454740:01C66563] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Both drafts should be adopted as WG docs.=20 Thanks Regards... Zafar =20 > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se]=20 > Sent: Friday, April 21, 2006 12:35 PM > To: mpls@ietf.org > Subject: [mpls] working group document candidates >=20 > All, >=20 > the authors of the two following drafts has requested that=20 > they are adopted as working group documents: >=20 > draft-vasseur-mpls-number-0-bw-te-lsps-00 > draft-leroux-mpls-mp-ldp-reqs-03.txt >=20 > draft-vasseur-... was discussed at the mpls wg meeting in=20 > Dallas. We had a good support for the general idea, but were=20 > uncertain how this should be handled document-wise. > The normal work flow would be that the mpls wg write a=20 > requirement draft to the ospf and is-is working groups, who=20 > each produce one spec for the extension for their protocols.=20 > It has however been argued that this could be addres in a=20 > single draft of less than a handful pages. > The (is-is, ospf and mpls) working group chairs and the=20 > routing area ADs have there fore agreed that we can do it in=20 > a single mpls working group document, which will be sent to=20 > the other two working groups for review. >=20 > draft-leroux-... was discussed at the same meeting, and there=20 > were a good support in the room for adopting it as a working=20 > group document. >=20 > Please respond to the mailing list whether you think they=20 > should become wg docs or not. >=20 > Loa and George >=20 > -- > Loa Andersson >=20 > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Apr 21 12:58:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWyvt-0002f4-2l; Fri, 21 Apr 2006 12:56:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWyvs-0002ez-3y for mpls@ietf.org; Fri, 21 Apr 2006 12:56:36 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWyvq-0002Jz-O7 for mpls@ietf.org; Fri, 21 Apr 2006 12:56:36 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 18:56:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] working group document candidates Date: Fri, 21 Apr 2006 18:56:31 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] working group document candidates Thread-Index: AcZlYfr+8c9y/T/cRuaIyBIO4PZk0AAAg+aA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Loa Andersson" , X-OriginalArrivalTime: 21 Apr 2006 16:56:32.0301 (UTC) FILETIME=[8A984DD0:01C66564] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org > draft-vasseur-mpls-number-0-bw-te-lsps-00 Yes > draft-leroux-mpls-mp-ldp-reqs-03.txt >=20 Yes! Cheers, JL > -----Message d'origine----- > De : Loa Andersson [mailto:loa@pi.se]=20 > Envoy=E9 : vendredi 21 avril 2006 18:35 > =C0 : mpls@ietf.org > Objet : [mpls] working group document candidates >=20 > All, >=20 > the authors of the two following drafts has requested that=20 > they are adopted as working group documents: >=20 > draft-vasseur-mpls-number-0-bw-te-lsps-00 > draft-leroux-mpls-mp-ldp-reqs-03.txt >=20 > draft-vasseur-... was discussed at the mpls wg meeting in=20 > Dallas. We had a good support for the general idea, but were=20 > uncertain how this should be handled document-wise. > The normal work flow would be that the mpls wg write a=20 > requirement draft to the ospf and is-is working groups, who=20 > each produce one spec for the extension for their protocols.=20 > It has however been argued that this could be addres in a=20 > single draft of less than a handful pages. > The (is-is, ospf and mpls) working group chairs and the=20 > routing area ADs have there fore agreed that we can do it in=20 > a single mpls working group document, which will be sent to=20 > the other two working groups for review. >=20 > draft-leroux-... was discussed at the same meeting, and there=20 > were a good support in the room for adopting it as a working=20 > group document. >=20 > Please respond to the mailing list whether you think they=20 > should become wg docs or not. >=20 > Loa and George >=20 > -- > Loa Andersson >=20 > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Apr 21 13:06:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWz2p-0005PQ-Lr; Fri, 21 Apr 2006 13:03:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWz2o-0005PL-7n for mpls@ietf.org; Fri, 21 Apr 2006 13:03:46 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWz2n-0002rQ-SG for mpls@ietf.org; Fri, 21 Apr 2006 13:03:46 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 19:03:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] working group document candidates Date: Fri, 21 Apr 2006 19:03:43 +0200 Message-ID: <5A0FF108221C7C4E85738678804B567C0332D455@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] working group document candidates Thread-Index: AcZlYgiEUaUVWjAXRKOVdyfShNdGQQAATYggAAByhkA= From: "DECRAENE Bruno RD-CORE-ISS" To: "Loa Andersson" , X-OriginalArrivalTime: 21 Apr 2006 17:03:43.0143 (UTC) FILETIME=[8B659370:01C66565] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Both drafts should be adopted as WG docs. Thanks, Regards Bruno > > -----Original Message----- > > From: Loa Andersson [mailto:loa@pi.se] > > Sent: Friday, April 21, 2006 12:35 PM > > To: mpls@ietf.org > > Subject: [mpls] working group document candidates > > > > All, > > > > the authors of the two following drafts has requested that > > they are adopted as working group documents: > > > > draft-vasseur-mpls-number-0-bw-te-lsps-00 > > draft-leroux-mpls-mp-ldp-reqs-03.txt > > > > draft-vasseur-... was discussed at the mpls wg meeting in > > Dallas. We had a good support for the general idea, but were > > uncertain how this should be handled document-wise. > > The normal work flow would be that the mpls wg write a > > requirement draft to the ospf and is-is working groups, who > > each produce one spec for the extension for their protocols. > > It has however been argued that this could be addres in a > > single draft of less than a handful pages. > > The (is-is, ospf and mpls) working group chairs and the > > routing area ADs have there fore agreed that we can do it in > > a single mpls working group document, which will be sent to > > the other two working groups for review. > > > > draft-leroux-... was discussed at the same meeting, and there > > were a good support in the room for adopting it as a working > > group document. > > > > Please respond to the mailing list whether you think they > > should become wg docs or not. > > > > Loa and George > > > > -- > > Loa Andersson > > > > Principal Networking Architect > > Acreo AB phone: +46 8 632 77 14 > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > Kista, Sweden email: loa.andersson@acreo.se > > loa@pi.se > > > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/mpls > > >=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 From mpls-bounces@lists.ietf.org Fri Apr 21 18:15:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX3rx-0006K7-3w; Fri, 21 Apr 2006 18:12:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX3rv-0006K2-Dr for mpls@ietf.org; Fri, 21 Apr 2006 18:12:51 -0400 Received: from pne-smtpout2-sn2.hy.skanova.net ([81.228.8.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX3rs-00031Z-SD for mpls@ietf.org; Fri, 21 Apr 2006 18:12:51 -0400 Received: from [127.0.0.1] (213.66.236.118) by pne-smtpout2-sn2.hy.skanova.net (7.2.070) id 444497C500112DB2 for mpls@ietf.org; Sat, 22 Apr 2006 00:12:42 +0200 Message-ID: <4449589E.8020808@pi.se> Date: Sat, 22 Apr 2006 00:11:42 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: multipart/mixed; boundary="------------080405050303030104000408" X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: Subject: [mpls] consolidated response to Q12/15 on T-MPLS 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: , Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --------------080405050303030104000408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Working Group, this is the consolidated list of concerns we've sent to the Q12/15. Note that we will further refine this list and send our formal response May 17th. Further comments are welcome. Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se --------------080405050303030104000408 Content-Type: text/plain; name="consolidated-list-of-concerns.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="consolidated-list-of-concerns.txt" Areas of concerns on Transport MPLS from the MPLS working group =============================================================== To: Q12/15 At this point, members of the IETF are expressing their concerns on Transport-MPLS on the MPLS and CCAMP mailing lists. We are working to collect and evaluate these and come to a consensus response to your liaison. The included somewhat consolidated list is still preliminary, e.g. it still lacks in structure. However we would like to alert you that our preliminary judgment is that some of the issues are of a serious nature. At least PHP, signaling protocol and reserved labels are of this serious nautre. More careful reading of the documents reveals that there is an appendix in G.8110.1 that addresses MPLS pseudowires. This document should also have been liaised to the PWE3 working group in the IETF as well. This appendix references draft-pan-pwe3-over-sub-ip-01 this draft is no longer active. Requirements ------------ We have not seen any requirements specification for T-MPLS. Penultimate Hop Popping (PHP) ----------------------------- We discussed this several times with different ITU-T SGs and Questions, we've agreed that the right way of stating this is that it is "mandatory to implement, optional to use" PHP. We would appreciate if the T-MPLS could adopt the same text. Note: We also think that it is a misconception to think that non-PHP is less complex than PHP. Signaling protocol ------------------ It is nowhere specified which signaling protocol will be used for for T-MPLS. It is also unclear if traffic engineering functionality is required. Note: if traffic engineering functionality is required, there is a strong recommendation from the IETF to use RSVP-TE. Note 2: If this effort leads to requirements on changes in the IETF signaling protocols this should be handled according to draft-andersson-rtg-gmpls-change-02. Non-merging ----------- T-MPLS states that merging of LSPs is not used. Merging was introduced to address the problem with a high number of LSPs in the core. How is the n-squared problem addressed in T-MPLS? Note: It is not a given that non-merging of LSPs from a protocol procedural or processing point of view necessarily is less complex than a merging variant. Reserved labels --------------- MPLS reserves label values 0-15 for special use. T-MPLS at one point also intended to reserve values 16-31 for similar use. It has been pointed out that this will make all existing MPLS implementations incompatible with T-MPLS. Labels 16-31 are said to be for further study. Some comments to the MPLS mailing list indicates that there is no plans to assign any semantics to labels 16-31. What is the reason to mention them if this is the case. In particular does the statement imply that these label values should be reserved. It is our opinion that: 1) If they are reserved then T-MPLS is incompatible with MPLS in a number of scenarios. It also would mean that T-MPLS is not a subset of MPLS (over and above the issue cited below). 2) If they are not reserved, reserving them in the future would cause intolerable deployment difficulties. In conclusion you should either say the labels are reserved and clearly declare that T-MPLS is not compatible with MPLS or remove the FFS text entirely. True subset of MPLS ------------------- It has been claimed that T-MPLS is a true subset of MPLS, yet the Y.1711 seems to be a part of T-MPLS. Y.1711 is not part of MPLS. If what is wanted is really a subset of MPLS, we believe several aspects has to be made clear - the exact relationship to MPLS - that enough functionality is there to make interoperability with MPLS possible - the MPLS OAM specification in RFC4377 has to be addressed There is previous art in defining similar "subsets" of MPLS, e.g. "draft-loa-mpls-cap-set-01.txt" and "draft-rosen-mpls-profiles-00.txt"; these efforts did not go very far since it was not obvious that they solved a real problem. In general it would be good to have a clear problem statement for T-MPLS. T-MPLS trademark ---------------- It has been brought to our notice that one of the parties active in developing the T-MPLS has a trademark on "T-MPLS". We don't know if this is a serious matter. Our postion on this is that IETF owns MPLS, though we never tried to trademark it, we are for open standards, and would see any attempt to use the MPLS and GMPLS technologies by means of trademarking as hostile. Interoperability at the MPLS / T-MPLS interface ----------------------------------------------- Several of the issues we have are for the interoperability between a T-MPLS device and an MPLS device. We can't see that these issues are discussed anywhere. We believe that these issues need to be addressed at least to make sure that there is no interoperability problems. Per platform or per interface labels +++++++++++++++++++++++++++++++++++ For a local link repair it is crucial whether the box you are talking to uses a per platform or per link label space. Note that if T-MPLS were to reserve labels 16-31 then T-MPLS cannot have a per platform label space if the platform also has mpls interfaces. These labels are *NOT* reserved by MPLS and are extremely likely to be allocated. I would also like it made clear as to whether they envision T-MPLS diverging on the interpretation of the EOS bit and the QoS/Exp bits. Global labels +++++++++++++ T-MPLS renames per platform labels "global labels", since global is an IETF term used to signify domain wide labels, is there a rationale for this renaming of platform to global? T-MPLS should align with the MPLS terminology. TTL management and LSP tunnels ++++++++++++++++++++++++++++++ RFC3443 describes how TTLs are handled in LSPs tunnels. The G.8110.1 state that it only supports RFC3443 for pipes and short pipes only. This is a potential incompatibility with MPLS over the interface between MPLS and T-MPLS networks. Interoperability over interface between MPLS and T-MPLS networks ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Some of the MPLS applications has been designed with certain MPLS features taken for granted, e.g.: - pseudowires assumes per platform labels - VPN assumes PHP - etc for these applications to work as before a T-MPLS box will need to have two types of interfaces. One interface that works as specified in T-MPLS and another interface that works as specified in MPLS. The T-MPLS needs to translate between the T-MPLS and the MPLS environment since this is not in the MPLS specifications from start. --------------080405050303030104000408 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 --------------080405050303030104000408-- From mpls-bounces@lists.ietf.org Sat Apr 22 05:02:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXDy5-0002TG-BL; Sat, 22 Apr 2006 04:59:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXDy3-0002TA-JK for mpls@lists.ietf.org; Sat, 22 Apr 2006 04:59:51 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXDy2-00036t-Jx for mpls@lists.ietf.org; Sat, 22 Apr 2006 04:59:51 -0400 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 22 Apr 2006 09:59:49 +0100 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Sat, 22 Apr 2006 09:59:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-lsp-ping-01.txt Date: Sat, 22 Apr 2006 09:59:47 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-lsp-ping-01.txt Thread-Index: AcZfCAUa7TYnQR2ARvWb5/DyhiQYHQGypSsA From: To: , X-OriginalArrivalTime: 22 Apr 2006 08:59:48.0750 (UTC) FILETIME=[1BF68AE0:01C665EB] X-Spam-Score: 0.3 (/) X-Scan-Signature: ff67cea9f7df2d77f61a364cea0926e8 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0227902544==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0227902544== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C665EB.1B7632EB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C665EB.1B7632EB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adrian, =20 Thanks for the response. Some comments inline marked BPN=3D>. =20 Ben =20 ________________________________ From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Thursday, April 13, 2006 3:38 PM To: Niven-jenkins,B,Ben,XDE73 R; mpls@lists.ietf.org Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-lsp-ping-01.txt=20 =09 =09 Hi Ben, =20 > 1) Why is it restricted to P2MP TE LSPs? mLDP signalled > LSPs will also require OAM and it's not clear to me why=20 > they have been precluded by this draft. =20 Well, this draft does *not* preclude mLDP. There are some factors to consider. a. When this draft was started, mLDP did not exist b. When this draft was developed there were two competing=20 mLDP solutions drafts and no clear definition of mLDP FECs. c. The existing MPLS-TE P2MP techniques are extensible (by use of a FEC) but it is not clear that the problem=20 space is the same with regard to scalability for mLDP. In particular, the ingress of an mLDP tree is (perhaps) not aware of the identities of the egresses and so it is hard to ping a single egress along the tree. d. What would be wrong about having two drafts for this? =20 Actually, at the last couple of IETFs (and on the list, if I recall) I have asked the question about whether to roll this all into one I-D or to keep it separate, and I have not had anything in the way of an answer.=20 =20 At the moment, we are inclined to keep the two pieces of work separate for cleanliness. But doing so does not imply that anyone thinks that mLDP should be without OAM.=20 =20 BPN=3D> OK. TBH I don't care if there is one piece of work or two but there is a clear requirement for OAM mechanisms for mLDP and I haven't seen any drafts that address this requirement, which is what prompted my question about mLDP being precluded. =20 =09 > 2) Section 4.1 of draft-ietf-mpls-p2mp-oam-reqs-01 states=20 > "The ability to detect defects in a P2MP LSP SHOULD not > require manual, hop-by-hop troubleshooting of each LSR=20 > used to switch traffic for that LSP, and SHOULD rely on > proactive OAM procedures (such as continuous path > connectivity and SLA measurement mechanisms)." whereas > the comments in draft-ietf-mpls-p2mp-lsp-ping-01 imply > to me that proactive/continuous OAM may not be possible > with the proposed solution due to scaling concerns > resulting from the possibility of flooding the ingress > with responses. =20 Hmmm. May be there are some semantics around "proactive" and "continuous". I think that these terms could be taken to mean that you should be able to initiate a "probe" at the ingress and rely on the probe mechanism to determine the existence of and location of the defect. This should happen without the operator having to initiate a probe hop-by-hop through the network along the path of the LSP. =20 BPN=3D> I interpret 'proactive' and 'continous' to mean that probe/ping/CC/CV (or whatever you want to call them) packets are (automatically) sent at regular intervals to detect faults, cf CV packets in Y.1711. =20 But we should also take into account that the proposed P2MP LSP Ping is not intended to be a solution for all requirements in the P2MP OAM Requirements I-D. Indeed, section 4.1 of the P2MP OAM Requirements I-D is quite clear about the issues of using LSP Ping for defect detection (compared with section 4.2 that describes defect diagnosis). =20 BPN=3D> OK, in which case it would be good to see some drafts describing other proposals/solutions. =20 Whether some other mechanism needs to be added to the toolkit (compare with BFD for P2P LSPs) for error detection is up for grabs, and I am sure that the working group would welcome contributions. =20 > As well as the ability to delay/jitter=20 > the echo responses has consideration been given to other > potential ways to improve scalability for example using a > Nack model for responses, somehow aggregating responses > etc.? =09 We did discuss a Nack model. I am not sure if it is what you are talking about.=20 =20 BPN=3D> I was just thinking out loud really... =20 In brief we considered... - OAM is enabled (see later) - Egress expects to receive "ping" every time unit - In the absence of a "ping" the egress sends an alert =20 We felt that OAM should not be permanently active on what may be a low bandwidth service for fear of being the main consumer of traffic. Therefore, OAM must be enabled by an explicit act (and not implicitly enabled by the establishment of the LSP). =20 Thus, we can say that OAM is enabled by the first ping. We would, of course, need a positive ack to that event. After that, we can resort to Nack processing. But I think there is some handshaking needed to make sure that the positive ack has been received. =20 Disabling is more of a worry. If the disable instruction does not reach an egress, it will continue to generate Nacks. Thus we would need some form of back-off on Nacks dropping quite quickly to assuming that OAM is disabled. =20 All of this is achievable, and could be built on top of LSP ping, but what is the cost/benefit? It is certainly a more complicated process, and I don't hear anyone suggesting that they plan to implement it. But if someone is working on such a solution, I'm sure we'd be happy to fold it in to our draft. =20 =20 Aggregation of responses was also briefly discussed. We have two problems with this. =20 1. How does the transit node know how long to hold on to a response in the hope that another will come along? In fact, won't any delay for aggregation simply serve to destroy the benefits of jitter? =20 2. What makes us assume that responses will follow paths that make aggregation practical? =20 =20 Cheers, Adrian ------_=_NextPart_001_01C665EB.1B7632EB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Adrian,
 
Thanks=20 for the response.  Some comments inline marked=20 BPN=3D>.
 
Ben
 

From: Adrian Farrel=20 [mailto:adrian@olddog.co.uk]
Sent: Thursday, April 13, 2006 = 3:38=20 PM
To: Niven-jenkins,B,Ben,XDE73 R;=20 mpls@lists.ietf.org
Subject: Re: [mpls] I-D=20 ACTION:draft-ietf-mpls-p2mp-lsp-ping-01.txt

Hi Ben,
 
> 1) Why is it restricted to = P2MP TE=20 LSPs?  mLDP signalled
> LSPs will also require = OAM and it's=20 not clear to me why
> they have been precluded by = this=20 draft.
 
Well, this draft does *not* = preclude=20 mLDP.
There are some factors to=20 consider.
a. When this draft was started, = mLDP did not=20 exist
b. When this draft was developed = there were two=20 competing
    mLDP solutions = drafts and no=20 clear definition of mLDP
   FECs.
c. The existing MPLS-TE P2MP = techniques are=20 extensible
    (by use of a = FEC) but it is=20 not clear that the problem
    space is the = same with=20 regard to scalability for mLDP.
    In particular, = the ingress=20 of an mLDP tree is (perhaps)
    not aware of the = identities=20 of the egresses and so it is
    hard to ping a = single egress=20 along the tree.
d. What would be wrong about having = two drafts=20 for this?
 
Actually, at the last couple of = IETFs (and on=20 the list, if I recall) I have asked the question about whether to roll = this=20 all into one I-D or to keep it separate, and I have not had anything = in the=20 way of an answer.
 
At the moment, we are = inclined to keep=20 the two pieces of work separate for cleanliness. But doing so does not = imply=20 that anyone thinks that mLDP should be without OAM. 
 
BPN=3D> OK.  TBH I don't = care if there is=20 one piece of work or two but there is a clear requirement for OAM = mechanisms for mLDP and I haven't seen any drafts that address this=20 requirement, which is what prompted my question about mLDP being=20 precluded.
  

> 2) Section 4.1 = of=20 draft-ietf-mpls-p2mp-oam-reqs-01 states
> "The ability to detect defects in a P2MP LSP SHOULD = not
> require manual, hop-by-hop troubleshooting of each LSR =
> used to switch traffic for that LSP, and SHOULD rely on
> proactive = OAM procedures (such as continuous = path
> connectivity and = SLA measurement mechanisms)." = whereas
> the comments=20 in draft-ietf-mpls-p2mp-lsp-ping-01 imply
> to me = that proactive/continuous OAM may not be = possible
> with the proposed solution due to scaling concerns
> resulting from the = possibility of=20 flooding the ingress
> with = responses.
 
Hmmm.
May be there are some semantics = around=20 "proactive" and "continuous".
I think that these terms could be = taken to mean=20 that you should be able to initiate a "probe" at the ingress and rely=20 on the probe mechanism to determine the existence of and location = of the=20 defect. This should happen without the operator having to initiate a = probe=20 hop-by-hop through the network along the path of the LSP.
 
BPN=3D> I=20 interpret 'proactive' and 'continous' to mean that probe/ping/CC/CV = (or=20 whatever you want to call them) packets are (automatically) sent at = regular=20 intervals to detect faults, cf CV packets in = Y.1711.
 
But we should also take into = account that=20 the proposed P2MP LSP Ping is not intended to be a solution for all=20 requirements in the P2MP OAM Requirements I-D. Indeed, section 4.1 of = the P2MP=20 OAM Requirements I-D is quite clear about the issues of using LSP Ping = for=20 defect detection (compared with section 4.2 that describes defect=20 diagnosis).
 
BPN=3D> OK, in=20 which case it would be good to see some drafts describing other=20 proposals/solutions.
 
Whether some other mechanism needs = to be added=20 to the toolkit (compare with BFD for P2P LSPs) for error detection is = up for=20 grabs, and I am sure that the working group would welcome=20 contributions.
 
> As well as the ability = to=20 delay/jitter
> the echo responses has = consideration=20 been given to other
> potential ways to improve = scalability=20 for example using a
> Nack model for responses, = somehow=20 aggregating responses
> etc.?
We did discuss a Nack model. = I am not=20 sure if it is what you are talking about. 
 
BPN=3D> I was just thinking out loud=20 really...
 
In brief we considered...
- OAM is enabled (see later)
- Egress expects to receive "ping" every time=20 unit
- In the absence of a "ping" the egress sends an=20 alert
 
We felt that OAM should not be permanently active = on what=20 may be a low bandwidth service for fear of being the main consumer of = traffic.=20 Therefore, OAM must be enabled by an explicit act (and not implicitly = enabled=20 by the establishment of the LSP).
 
Thus, we can say that OAM is enabled by the first = ping. We=20 would, of course, need a positive ack to that event. After that, we = can resort=20 to Nack processing. But I think there is some handshaking needed to = make sure=20 that the positive ack has been received.
 
Disabling is more of a worry. If the disable = instruction=20 does not reach an egress, it will continue to generate Nacks. Thus we = would=20 need some form of back-off on Nacks dropping quite quickly to assuming = that=20 OAM is disabled.
 
All of this is achievable, and could be built on = top of LSP=20 ping, but what is the cost/benefit? It is certainly a more complicated = process, and I don't hear anyone suggesting that they plan to = implement it.=20 But if someone is working on such a solution, I'm sure we'd be happy = to fold=20 it in to our draft.
 
 
Aggregation of responses was also briefly = discussed. We have=20 two problems with this.
 
1. How does the transit node know how long to hold = on to a=20 response in the hope that another will come along? In fact, won't any = delay=20 for aggregation simply serve to destroy the benefits of = jitter?
 
2. What makes us assume that responses will follow = paths=20 that make aggregation practical?
 
 
Cheers,
Adrian
------_=_NextPart_001_01C665EB.1B7632EB-- --===============0227902544== 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 --===============0227902544==-- From necojp@citiz.net Sun Apr 23 02:45:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXYLG-0002St-42 for MPLS-ARCHIVE@LISTS.IETF.ORG; Sun, 23 Apr 2006 02:45:10 -0400 Received: from [218.9.250.211] (helo=a-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXYL2-0006Oh-O8 for MPLS-ARCHIVE@LISTS.IETF.ORG; Sun, 23 Apr 2006 02:45:10 -0400 Received: from oljzwifg8 (unknown [220.152.127.238]) by smtp70 (Coremail) with SMTP id Sky8twLvoJ9Es1nB.1 for ; Sun, 23 Apr 2006 14:44:46 +0800 (CST) X-Originating-IP: [220.152.127.238] Subject: =?iso-2022-jp?B?GyRCIVpLXEVQTz8kTiQqQ04kaSQ7IVsbKEI=?= From: =?gb2312?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C6629D.6C392630" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C6629D.6C392630 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCISEhISEhISEhISEhIWEhYSQqQ04kaSQ7IWEhYRsoQg0KGyRCISEhISEhISEhISEhISEhISEh Mj5FUE8/JCw0ME47Q1ckNyReJDckPyEqGyhCDQobJEIhISInMjw1LSROGyhCVVJMGyRCJGgkaiVR JTklbyE8JUkkckZ+Tk8kNyRGJW0lMCUkJXMkNyRGMjwkNSQkGyhCDQobJEIhISEhISEbKEJodHRw Oi8vd3d3LmhpbWl0c3Vuby1zYXNheWFraTYubmV0Lz9oYXJ1MjIzDQoNCg0KGyRCISEhISIoJW0l MCUkJXMbKEJJRBskQiEmJVElOSVvITwlSSRPQmdAWiRLSl00SSQ3JEYkLyRAJDUkJCEjGyhCDQob JEIhISEhIigkMyROJWEhPCVrJFgkTkpWPy4kTkksTVckTyQiJGokXiQ7JHMhIxsoQg0KDQoNCg0K PT09PT09PT09PT09PT09PQ0KGyRCJDQ8QUxkISYkKkxkOWckOxsoQg0KPT09PT09PT09PT09PT09 PQ0KGyRCISEiJyQ0PEFMZEV5JE8hIjI8NS0bKEJVUkwbJEIkXiRHJCo1JDdaJEskKkxkJCQ5ZyRv JDsyPCQ1JCQhIxsoQg0KGyRCIVpMZCQkOWckbyQ7IVsiTSEhGyhCaHR0cDovL3d3dy5oaW1pdHN1 bm8tc2FzYXlha2k2Lm5ldC8/aGFydTIyMw0KDQoNCg0KDQoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQobJEJFdiU1JSQlSCRHJE8wLTU6TFxF KiEiMC08QTZIPFRFeSRPMGxAWkdTPXxDVyQ3JEYkKiRqJF4kOSEjGyhCDQobJEIhISEhISEhIRso QjE4GyRCOlBMJEt+JE5KfSROJDRNeE1RJE8kKkNHJGokNyRGJCQkXiQ5ISMbKEINCg0KGyRCJCpD TiRpJDtJVE1XJE8kMyRBJGkkWCIqISEbKEJvZmZpY2VfbmV3c19oaW1pdHN1QHlhaG9vLmNvLmpw DQoNCnJlZnVzZSBhbiBlbWFpbBskQiIqISEbKEJvZmZpY2VfbmV3c19oaW1pdHN1QHlhaG9vLmNv LmpwDQoNCg== ------=_NextPart_000_0009_01C6629D.6C392630 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjE4MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9 Mj4NCjxESVY+PEZPTlQgc2l6ZT01PhskQiEhISEhISEhISEhISFhIWEkKkNOJGkkOyFhIWEbKEI8 QlI+PC9GT05UPjxGT05UIA0Kc2l6ZT0zPhskQiEhISEhISEhISEhISEhISEhITI+RVBPPyQsNDBO O0NXJDckXiQ3JD8hKhsoQjxCUj4bJEIhISInMjw1LSROGyhCVVJMGyRCJGgkaiVRJTklbyE8JUkk ckZ+Tk8kNyRGJW0lMCUkJXMkNyRGMjwkNSQkGyhCPEJSPhskQiEhISEhIRsoQjxBIA0KaHJlZj0i aHR0cDovL3d3dy5oaW1pdHN1bm8tc2FzYXlha2k2Lm5ldC8/aGFydTIyMyI+aHR0cDovL3d3dy5o aW1pdHN1bm8tc2FzYXlha2k2Lm5ldC8/aGFydTIyMzwvQT48L0ZPTlQ+PEZPTlQgDQpzaXplPTM+ PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEJSPjxGT05UIA0Kc2l6ZT0z PhskQiEhISEiKCVtJTAlJCVzGyhCSUQbJEIhJiVRJTklbyE8JUkkT0JnQFokS0pdNEkkNyRGJC8k QCQ1JCQhIxsoQjxCUj4bJEIhISEhIigkMyROJWEhPCVrJFgkTkpWPy4kTkksTVckTyQiJGokXiQ7 JHMhIxsoQjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj48QlI+PEZPTlQgDQpzaXplPTM+PT09PT09PT09PT09PT09PTxCUj4bJEIkNDxBTGQh JiQqTGQ5ZyQ7GyhCPEJSPj09PT09PT09PT09PT09PT08QlI+GyRCISEiJyQ0PEFMZEV5JE8hIjI8 NS0bKEJVUkwbJEIkXiRHJCo1JDdaJEskKkxkJCQ5ZyRvJDsyPCQ1JCQhIxsoQjxCUj4bJEIhWkxk JCQ5ZyRvJDshWyJNISEbKEI8QSANCmhyZWY9Imh0dHA6Ly93d3cuaGltaXRzdW5vLXNhc2F5YWtp Ni5uZXQvP2hhcnUyMjMiPmh0dHA6Ly93d3cuaGltaXRzdW5vLXNhc2F5YWtpNi5uZXQvP2hhcnUy MjM8L0E+PC9GT05UPjxGT05UIA0Kc2l6ZT0zPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0zPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+KioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKio8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PhskQkV2JTUlJCVIJEckTzAtNTpMXEUqISIwLTxBNkg8VEV5JE8wbEBaR1M9fENXJDckRiQqJGok XiQ5ISMbKEI8L0RJVj4NCjxESVY+GyRCISEhISEhISEbKEIxOBskQjpQTCRLfiROSn0kTiQ0TXhN USRPJCpDRyRqJDckRiQkJF4kOSEjGyhCPC9ESVY+DQo8RElWPjxCUj4bJEIkKkNOJGkkO0lUTVck TyQzJEEkaSRYIiohIRsoQjxBIA0KaHJlZj0ibWFpbHRvOm9mZmljZV9uZXdzX2hpbWl0c3VAeWFo b28uY28uanAiPm9mZmljZV9uZXdzX2hpbWl0c3VAeWFob28uY28uanA8L0E+PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj5yZWZ1c2UgYW4gZW1haWwbJEIiKiEhGyhCPEEgDQpocmVmPSJt YWlsdG86b2ZmaWNlX25ld3NfaGltaXRzdUB5YWhvby5jby5qcCI+b2ZmaWNlX25ld3NfaGltaXRz dUB5YWhvby5jby5qcDwvQT48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjwvRk9OVD4m bmJzcDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0009_01C6629D.6C392630-- From mpls-bounces@lists.ietf.org Sun Apr 23 04:59:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXaOb-0005bD-Ur; Sun, 23 Apr 2006 04:56:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXaOZ-0005b5-Kr for mpls@ietf.org; Sun, 23 Apr 2006 04:56:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXZNh-0000IG-7G for mpls@ietf.org; Sun, 23 Apr 2006 03:51:45 -0400 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FXZ9L-0000x5-4E for mpls@ietf.org; Sun, 23 Apr 2006 03:36:57 -0400 Received: from usruamalisl.mail.com (dialup-80-254-78-1.dclient.monzoon.net[80.254.78.1]) by comcast.net (sccrmhc11) with SMTP id <2006042307365101100saocbe>; Sun, 23 Apr 2006 07:36:51 +0000 Message-Id: <7.0.1.0.2.20060423032510.064308b0@comcast.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 23 Apr 2006 03:36:36 -0400 To: Loa Andersson From: "Andrew G. Malis" Subject: Re: [mpls] consolidated response to Q12/15 on T-MPLS In-Reply-To: <4449589E.8020808@pi.se> References: <4449589E.8020808@pi.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.1 (-) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 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: , Errors-To: mpls-bounces@lists.ietf.org Loa, Good summary of the discussion so far. I think we should ask Q12/15 for clarification on is how MPLS and T-MPLS equipment are expected or required to interoperate. As I understand it, T-MPLS operates at the transport layer (layer 1), and as such may provide transport services for MPLS networks. In this scenario, there may be a physical or logical interface between an MPLS LSR and a T-MPLS switch, so that MPLS packets may be transported on T-MPLS LSPs at Layer 1. One could (should?) expect that the MPLS packets arriving on such an interface (say, PoS as an example) would be transparently transported across the T-MPLS network to the destination LSR. In this scenario, the MPLS LSRs are CEs to the T-MPLS network. So, I guess we need to know whether or not the T-MPLS equipment will do any MPLS-layer processing of the packets, or simply transparently transport them without inspection or change, and what signaling (if any) would be used across this interface. The details of this interface would will dictate the interoperability requirements between MPLS LSRs and T-MPLS switches. Cheers, Andy ------------- At 4/22/2006 00:11 +0200, Loa Andersson wrote: >Working Group, > >this is the consolidated list of concerns we've sent to the Q12/15. > >Note that we will further refine this list and send our formal >response May 17th. Further comments are welcome. > >Loa and George > >-- >Loa Andersson > >Principal Networking Architect >Acreo AB phone: +46 8 632 77 14 >Isafjordsgatan 22 mobile: +46 739 81 21 64 >Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > > > >Areas of concerns on Transport MPLS from the MPLS working group >=============================================================== > >To: Q12/15 > >At this point, members of the IETF are expressing their concerns on >Transport-MPLS on the MPLS and CCAMP mailing lists. We are working >to collect and evaluate these and come to a consensus response to >your liaison. > >The included somewhat consolidated list is still preliminary, e.g. >it still lacks in structure. > >However we would like to alert you that our preliminary judgment is >that some of the issues are of a serious nature. At least PHP, >signaling protocol and reserved labels are of this serious nautre. > >More careful reading of the documents reveals that there is an >appendix in G.8110.1 that addresses MPLS pseudowires. This document >should also have been liaised to the PWE3 working group in the >IETF as well. This appendix references draft-pan-pwe3-over-sub-ip-01 >this draft is no longer active. > >Requirements >------------ >We have not seen any requirements specification for T-MPLS. > >Penultimate Hop Popping (PHP) >----------------------------- >We discussed this several times with different ITU-T SGs and >Questions, we've agreed that the right way of stating this is >that it is "mandatory to implement, optional to use" PHP. We >would appreciate if the T-MPLS could adopt the same text. > >Note: We also think that it is a misconception to think that >non-PHP is less complex than PHP. > >Signaling protocol >------------------ >It is nowhere specified which signaling protocol will be used for >for T-MPLS. > >It is also unclear if traffic engineering functionality is required. > >Note: if traffic engineering functionality is required, there >is a strong recommendation from the IETF to use RSVP-TE. > >Note 2: If this effort leads to requirements on changes in the IETF >signaling protocols this should be handled according to >draft-andersson-rtg-gmpls-change-02. > >Non-merging >----------- >T-MPLS states that merging of LSPs is not used. > >Merging was introduced to address the problem with a high number >of LSPs in the core. How is the n-squared problem addressed in >T-MPLS? > >Note: It is not a given that non-merging of LSPs from a protocol >procedural or processing point of view necessarily is less >complex than a merging variant. > >Reserved labels >--------------- >MPLS reserves label values 0-15 for special use. T-MPLS at one point >also intended to reserve values 16-31 for similar use. It has been >pointed out that this will make all existing MPLS implementations >incompatible with T-MPLS. > >Labels 16-31 are said to be for further study. Some comments to the >MPLS mailing list indicates that there is no plans to assign any >semantics to labels 16-31. What is the reason to mention them if >this is the case. > >In particular does the statement imply that these label values should be >reserved. It is our opinion that: > >1) If they are reserved then T-MPLS is incompatible with MPLS in a > number of scenarios. It also would mean that T-MPLS is not a subset > of MPLS (over and above the issue cited below). > >2) If they are not reserved, reserving them in the future would cause > intolerable deployment difficulties. > >In conclusion you should either say the labels are reserved and clearly >declare that T-MPLS is not compatible with MPLS or remove the FFS text >entirely. > > >True subset of MPLS >------------------- >It has been claimed that T-MPLS is a true subset of MPLS, yet the >Y.1711 seems to be a part of T-MPLS. Y.1711 is not part of MPLS. > >If what is wanted is really a subset of MPLS, we believe several aspects >has to be made clear >- the exact relationship to MPLS >- that enough functionality is there to make interoperability with > MPLS possible >- the MPLS OAM specification in RFC4377 has to be addressed > >There is previous art in defining similar "subsets" of MPLS, >e.g. "draft-loa-mpls-cap-set-01.txt" and >"draft-rosen-mpls-profiles-00.txt"; these efforts did not go very far >since it was not obvious that they solved a real problem. >In general it would be good to have a clear problem statement for >T-MPLS. > >T-MPLS trademark >---------------- >It has been brought to our notice that one of the parties active >in developing the T-MPLS has a trademark on "T-MPLS". We don't >know if this is a serious matter. Our postion on this is that >IETF owns MPLS, though we never tried to trademark it, we are for >open standards, and would see any attempt to use the MPLS and >GMPLS technologies by means of trademarking as hostile. > >Interoperability at the MPLS / T-MPLS interface >----------------------------------------------- >Several of the issues we have are for the interoperability between >a T-MPLS device and an MPLS device. We can't see that these issues >are discussed anywhere. We believe that these issues need to be >addressed at least to make sure that there is no interoperability >problems. > >Per platform or per interface labels >+++++++++++++++++++++++++++++++++++ >For a local link repair it is crucial whether the box you are >talking to uses a per platform or per link label space. > >Note that if T-MPLS were to reserve labels 16-31 >then T-MPLS cannot have a per platform label space if the platform also >has mpls interfaces. These labels are *NOT* reserved by MPLS and are >extremely likely to be allocated. > >I would also like it made clear as to whether they envision T-MPLS >diverging on the interpretation of the EOS bit and the QoS/Exp bits. > >Global labels >+++++++++++++ >T-MPLS renames per platform labels "global labels", since global is >an IETF term used to signify domain wide labels, is there a >rationale for this renaming of platform to global? T-MPLS should >align with the MPLS terminology. > >TTL management and LSP tunnels >++++++++++++++++++++++++++++++ >RFC3443 describes how TTLs are handled in LSPs tunnels. The G.8110.1 >state that it only supports RFC3443 for pipes and short pipes only. >This is a potential incompatibility with MPLS over the interface >between MPLS and T-MPLS networks. > >Interoperability over interface between MPLS and T-MPLS networks >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >Some of the MPLS applications has been designed with certain MPLS >features taken for granted, e.g.: > >- pseudowires assumes per platform labels >- VPN assumes PHP >- etc > >for these applications to work as before a T-MPLS box will need to >have two types of interfaces. One interface that works as specified >in T-MPLS and another interface that works as specified in MPLS. >The T-MPLS needs to translate between the T-MPLS and the MPLS >environment since this is not in the MPLS specifications from start. > > > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sun Apr 23 06:39:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXbyC-0007vW-12; Sun, 23 Apr 2006 06:37:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXbyA-0007u5-Ao for mpls@ietf.org; Sun, 23 Apr 2006 06:37:34 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXby9-00051X-1e for mpls@ietf.org; Sun, 23 Apr 2006 06:37:34 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 23 Apr 2006 03:37:33 -0700 X-IronPort-AV: i="4.04,149,1144047600"; d="scan'208"; a="1797823922:sNHT31293704" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k3NAbVVI024606; Sun, 23 Apr 2006 03:37:32 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 23 Apr 2006 06:37:31 -0400 Received: from [127.0.0.1] ([161.44.11.166]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 23 Apr 2006 06:37:31 -0400 Message-ID: <444B58E9.3050801@employees.org> Date: Sun, 23 Apr 2006 06:37:29 -0400 From: Scott W Brim User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Andrew G. Malis" Subject: Re: [mpls] consolidated response to Q12/15 on T-MPLS References: <4449589E.8020808@pi.se> <7.0.1.0.2.20060423032510.064308b0@comcast.net> In-Reply-To: <7.0.1.0.2.20060423032510.064308b0@comcast.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2006 10:37:31.0209 (UTC) FILETIME=[ECAC8B90:01C666C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org On 04/23/2006 03:36 AM, Andrew G. Malis allegedly wrote: > So, I guess we need to know whether or not the T-MPLS equipment will do > any MPLS-layer processing of the packets, or simply transparently > transport them without inspection or change, and what signaling (if any) > would be used across this interface. That's the plan as far as I know, but I don't think it has been completely spelled out. Another interesting scenario is where a device has both "full" MPLS and T-MPLS LSPs on the same interface. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sun Apr 23 10:41:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXfjQ-0002th-S6; Sun, 23 Apr 2006 10:38:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXfjP-0002tc-HX for mpls@ietf.org; Sun, 23 Apr 2006 10:38:35 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXfjP-0008MH-4m for mpls@ietf.org; Sun, 23 Apr 2006 10:38:35 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Apr 2006 16:38:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [mpls] working group document candidates Date: Sun, 23 Apr 2006 16:38:25 +0200 Message-ID: <8AA97249241F7148BE6D3D8B93D83F5A09CF6B52@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [mpls] working group document candidates Thread-Index: AcZlYgVMJleU7o7BSAqCdW3C4C9BGgBgYI7A From: "JACQUENET Christian RD-TCH-REN" To: "Loa Andersson" , X-OriginalArrivalTime: 23 Apr 2006 14:38:29.0340 (UTC) FILETIME=[966441C0:01C666E3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0826799424==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0826799424== Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0008_01C666F4.56CC70D0"; protocol="application/x-pkcs7-signature" This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C666F4.56CC70D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I also favor the adoption of both drafts. Cheers, Christian.=20 -----Message d'origine----- De : Loa Andersson [mailto:loa@pi.se]=20 Envoy=E9 : vendredi 21 avril 2006 18:35 =C0 : mpls@ietf.org Objet : [mpls] working group document candidates All, the authors of the two following drafts has requested that they are = adopted as working group documents: draft-vasseur-mpls-number-0-bw-te-lsps-00 draft-leroux-mpls-mp-ldp-reqs-03.txt draft-vasseur-... was discussed at the mpls wg meeting in Dallas. We had = a good support for the general idea, but were uncertain how this should be handled document-wise. The normal work flow would be that the mpls wg write a requirement draft = to the ospf and is-is working groups, who each produce one spec for the extension for their protocols. It has however been argued that this = could be addres in a single draft of less than a handful pages. The (is-is, ospf and mpls) working group chairs and the routing area ADs have there fore agreed that we can do it in a single mpls working group document, which will be sent to the other two working groups for review. draft-leroux-... was discussed at the same meeting, and there were a = good support in the room for adopting it as a working group document. Please respond to the mailing list whether you think they should become = wg docs or not. Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls ------=_NextPart_000_0008_01C666F4.56CC70D0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISbDCCBIAw ggNooAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDkZyYW5j ZSBUZWxlY29tMRMwEQYDVQQLEwpGVFJELUFzcGljMRcwFQYDVQQDEw5GVFJEIEFDIFJhY2luZTAe Fw0wMjEwMDMwNzA3NThaFw0xMjEwMDIwNzA3NThaMFQxCzAJBgNVBAYTAkZSMRcwFQYDVQQKEw5G cmFuY2UgVGVsZWNvbTETMBEGA1UECxMKRlRSRC1Bc3BpYzEXMBUGA1UEAxMORlRSRCBBQyBSYWNp bmUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDfNb9DTp38mMZszg1TJwHeONcylQu+ PXC7oOjphIYne0HQQHUSXjKDKJ7vblnTkArsr3Ruu1QrAOvOmkmwz8k06M03hcGZ0Y928oWa3KG6 idksdKwNj40JqWbpIEkt5fAsNDp2TuZaUGUgXzieBdDkY3uyFq0G/EG6T7f3Gwj4nu2Y4VIpa947 Nk0ljwFK4WSSqdDTUh8ZOVfpaAfsUi6laynWFpaIquEa4xKVy/O/djTMEelEZva8ADibtC8GFNO6 uoiyjiNdOqk7ynoy1cQC+frE+WFiv7m4vIXS4VvLvQsTk5knyfaWPANRYqj8lnCd4B0s9iLUbx9p iatXPyLjAgMBAAGjggFbMIIBVzASBgNVHRMBAf8ECDAGAQH/AgEBMB0GA1UdDgQWBBS3Se6TQSJ/ 2aiXlSc+ZGaerhg/AzB8BgNVHSMEdTBzgBS3Se6TQSJ/2aiXlSc+ZGaerhg/A6FYpFYwVDELMAkG A1UEBhMCRlIxFzAVBgNVBAoTDkZyYW5jZSBUZWxlY29tMRMwEQYDVQQLEwpGVFJELUFzcGljMRcw FQYDVQQDEw5GVFJEIEFDIFJhY2luZYIBADAOBgNVHQ8BAf8EBAMCAQYwgYAGA1UdHwR5MHcwP6A9 oDuGOWh0dHA6Ly9sdWNpZmVyLnJkLmZyYW5jZXRlbGVjb20uZnIvcmV2b3F1ZXMvY3JscmFjaW5l LmNybDA0oDKgMIYuaHR0cDovL3BraS1sLnJkLmZyYW5jZXRlbGVjb20uZnIvY3JscmFjaW5lLmNy bDARBglghkgBhvhCAQEEBAMCAAcwDQYJKoZIhvcNAQEFBQADggEBAGi8vbslCQ47x0nr1vZXWmbB vs5e0NSfj5zDzgn32B3ShyOv67c6dEvq1BjFhHRfNhcRpxmiE9P4HOqftoD7/v92MRloG9GgSucR I8SHn5oQO6xisabqxquD5hI+G+mHv2fYUwRZRSNiMbudc5OIRLx6JMvKBXUHc29vaueNaRQbD+6m 4ncYuts5asRO0uGcftys5HoAySCepOF1yt9O41GCQW5wu2gaHUk+j9iPKk13JRu6k5Cn/8M8tcvA 0skajQAaF+ly3kMjPaJhqygEYXQoLDFC6DzUQDCNTdZ9w5Qwin1oyZe1lWmssMihlZokiiJ22LTO VwdoaGhKydWRJN0wggSIMIIDcKADAgECAgEBMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNVBAYTAkZS MRcwFQYDVQQKEw5GcmFuY2UgVGVsZWNvbTETMBEGA1UECxMKRlRSRC1Bc3BpYzEXMBUGA1UEAxMO RlRSRCBBQyBSYWNpbmUwHhcNMDIxMDAzMDcxNTIwWhcNMTIxMDAyMDcxNTIwWjBcMQswCQYDVQQG EwJGUjEXMBUGA1UEChMORnJhbmNlIFRlbGVjb20xEzARBgNVBAsTCkZUUkQtQXNwaWMxHzAdBgNV BAMTFkZUUkQgQUMgb3BlcmF0aW9ubmVsbGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDyhK63MkH/rYERgbIgUChhp74XjBfhO+FwEZJA6zZy/6AOcOnvejY+Xhe03aIhOwCEEbzlKyZC PcT++LMw1D/wjwT1ccS9POeacqB/6gXIHVQlVgQyhhq6HPQOTnl7CgonrW9cuPj1eSXkFcN3uNb6 idOlLfNUGD5GfOLiUiIkTaGmRvnQWATnz/KS9xo9o51+d3rJX3Yl47JTJO4nG73LwLgZcx1Py5Cz R2Vf4hCRhn491/JDjBdHt79TpQF/k1xGJbwOOsJ336lTCIIohWwBzzgTCKjjDlUF8dknaJEXKQLB 7W/C3Gi60rHg3/25s74ZLn6eqmKFKDQvbOIOPCfRAgMBAAGjggFbMIIBVzASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdDgQWBBSnh7jQi/Rv48HA2u2OtOCnECn82DB8BgNVHSMEdTBzgBS3Se6TQSJ/ 2aiXlSc+ZGaerhg/A6FYpFYwVDELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDkZyYW5jZSBUZWxlY29t MRMwEQYDVQQLEwpGVFJELUFzcGljMRcwFQYDVQQDEw5GVFJEIEFDIFJhY2luZYIBADAOBgNVHQ8B Af8EBAMCAQYwgYAGA1UdHwR5MHcwP6A9oDuGOWh0dHA6Ly9sdWNpZmVyLnJkLmZyYW5jZXRlbGVj b20uZnIvcmV2b3F1ZXMvY3JscmFjaW5lLmNybDA0oDKgMIYuaHR0cDovL3BraS1sLnJkLmZyYW5j ZXRlbGVjb20uZnIvY3JscmFjaW5lLmNybDARBglghkgBhvhCAQEEBAMCAAcwDQYJKoZIhvcNAQEF BQADggEBALaNFmEzT8zTf163U9ueSMDym2C2Q/2EX0MMHGweBX+hfSpvievSi6WWWcdGf/K07I1R XNwNkB0zMuDgdrydajzFDviZWoaoR27p+Bh8TNMZfasxgGr3qOcbyDKh2FJ50WerPC2nUFW5HB8Y MOKD5MERmyqBsk+lhHRYVpp+ATgbsFETfyS+C8p05MBxJJQ24XhMgFUzqySG2fPK1gCjqEsw4Q/l rv2Vb23GLmDXr6mnyXHg9YOq0IWs+zuB5xnZomrt/2sle2TQ6sZ5tEn5YuK+JbU4uhpMZhKE+19S XSrh9J2tGXWEaKsUaKTPLi7BTDh3OOhk+x8LDXKl3LUaTkQwggSIMIIDcKADAgECAgIpXTANBgkq hkiG9w0BAQUFADBcMQswCQYDVQQGEwJGUjEXMBUGA1UEChMORnJhbmNlIFRlbGVjb20xEzARBgNV BAsTCkZUUkQtQXNwaWMxHzAdBgNVBAMTFkZUUkQgQUMgb3BlcmF0aW9ubmVsbGUwHhcNMDUxMTAy MDc1MzAwWhcNMDgxMTAxMDc1MzAwWjCBqTELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDkZyYW5jZSBU ZWxlY29tMRMwEQYDVQQLEwpGVFJELUFTUElDMRwwGgYDVQQDExNDaHJpc3RpYW4gSkFDUVVFTkVU MRgwFgYKCZImiZPyLGQBARMIQ1VPSjY0OTUxNDAyBgkqhkiG9w0BCQEWJWNocmlzdGlhbi5qYWNx dWVuZXRAZnJhbmNldGVsZWNvbS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI5j6RyB L02I6Pw513AQd+08UCMNefpzuC7rmhyYlcymBTRm0gshguxMrD2yPYE2b69XzrGFNMaAbgvcKOlV 2+vHz3uSmLnpFpNNTw+OEY8C+HxQf0PcNphwqZ00DDVovuFLwrAGS8WJ6zjMY09+SqjEYxMEBvQw SF+0zcgFGwAjAgMBAAGjggGIMIIBhDAPBgNVHQ8BAf8EBQMDBzAAMBMGA1UdJQQMMAoGCCsGAQUF BwMEMB0GA1UdDgQWBBTIH0eCwyQv2G83S4IXC2hoETZnzzBjBgNVHSMEXDBagBSnh7jQi/Rv48HA 2u2OtOCnECn82KE/gT1DPUZSLE89RnJhbmNlIFRlbGVjb20sT1U9RlRSRC1Bc3BpYyxDTj1GVFJE IEFDIG9wZXJhdGlvbm5lbGxlggEBMDAGA1UdEQQpMCeBJWNocmlzdGlhbi5qYWNxdWVuZXRAZnJh bmNldGVsZWNvbS5jb20wgZIGA1UdHwSBijCBhzBHoEWgQ4ZBaHR0cDovL2x1Y2lmZXIucmQuZnJh bmNldGVsZWNvbS5mci9yZXZvcXVlcy9jcmxvcGVyYXRpb25uZWxsZS5jcmwwPKA6oDiGNmh0dHA6 Ly9wa2ktbC5yZC5mcmFuY2V0ZWxlY29tLmZyL2NybG9wZXJhdGlvbm5lbGxlLmNybDARBglghkgB hvhCAQEEBAMCBSAwDQYJKoZIhvcNAQEFBQADggEBAGrO8Ol7eG7K4wCSakCvC6R4YoenoyESMfOS UlT2Z2u3FvfzhrGCMH3PWvIsPEbd5ckqVsGiejiLkx9MjxVEoXn2KiIAkvs2MC20gEm5clt2D4Sc hqZw722THQbykuYbUFI3WfrXCDudIDxsbfmjGdcEqWaqGsv3d5mvNz6rFIpMSl+HVBYg+JSU5gc4 JzR8LEXUKoXtMo/krPd2lP8MJ3dYsxhL6z+14Tksn2nBC9JGwotwnOTu9jjuAdzlZ0YCREYa8FFZ k2/6NrzdGk0y5QmBGbdRTD0EYNhUytAI9i55WmyEIncNVrOflaWDGwuZrWyCSsd+3cnDANZHmII9 lVswggTMMIIDtKADAgECAgIpXDANBgkqhkiG9w0BAQUFADBcMQswCQYDVQQGEwJGUjEXMBUGA1UE ChMORnJhbmNlIFRlbGVjb20xEzARBgNVBAsTCkZUUkQtQXNwaWMxHzAdBgNVBAMTFkZUUkQgQUMg b3BlcmF0aW9ubmVsbGUwHhcNMDUxMTAyMDc1MzAwWhcNMDgxMTAxMDc1MzAwWjCBqTELMAkGA1UE BhMCRlIxFzAVBgNVBAoTDkZyYW5jZSBUZWxlY29tMRMwEQYDVQQLEwpGVFJELUFTUElDMRwwGgYD VQQDExNDaHJpc3RpYW4gSkFDUVVFTkVUMRgwFgYKCZImiZPyLGQBARMIQ1VPSjY0OTUxNDAyBgkq hkiG9w0BCQEWJWNocmlzdGlhbi5qYWNxdWVuZXRAZnJhbmNldGVsZWNvbS5jb20wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAIYpsd1SlUxVr2nFetlHYFdlzKcuzgaul9iIeP+Er9fG5k3db+me loVOE6Rq36/PUc0dQI96y0S/6ikA2ngThBbnRgwo9IzbmrG/su2sn67blTp09V3KyB6aURTWP8ut WSKhmKE9oW06IKljwr5OqCrZvcj5cmVCsSI86QcWhkYLAgMBAAGjggHMMIIByDAPBgNVHQ8BAf8E BQMDB8AAMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4E FgQUjUy3wECsj5bybBj/LAQhnD/nAdAwYwYDVR0jBFwwWoAUp4e40Iv0b+PBwNrtjrTgpxAp/Nih P4E9Qz1GUixPPUZyYW5jZSBUZWxlY29tLE9VPUZUUkQtQXNwaWMsQ049RlRSRCBBQyBvcGVyYXRp b25uZWxsZYIBATBeBgNVHREEVzBVoCwGCisGAQQBgjcUAgOgHgwcY3VvajY0OTVAcmQuZnJhbmNl dGVsZWNvbS5mcoElY2hyaXN0aWFuLmphY3F1ZW5ldEBmcmFuY2V0ZWxlY29tLmNvbTCBkgYDVR0f BIGKMIGHMEegRaBDhkFodHRwOi8vbHVjaWZlci5yZC5mcmFuY2V0ZWxlY29tLmZyL3Jldm9xdWVz L2NybG9wZXJhdGlvbm5lbGxlLmNybDA8oDqgOIY2aHR0cDovL3BraS1sLnJkLmZyYW5jZXRlbGVj b20uZnIvY3Jsb3BlcmF0aW9ubmVsbGUuY3JsMBEGCWCGSAGG+EIBAQQEAwIFoDANBgkqhkiG9w0B AQUFAAOCAQEAMNFMUakrUfguhUZPBQKgNyhx+2jHjwE0n/rTPSN81EY5bcEi9KCSk6hJx8mqg5mt XtADNxl2SqxGhKS24VpaCKXHSpKj+IOSJGhie6lmbrWkeqV6wgkExIm1tZjOj+0RegW3txIZ9eFC wbixZya+J9+lJwHAcXExx5EGcGOPf8LpTSg7oqX/Ss3suWzMuj+IC8oW8ce6AotRgCGaJI7EAR3f Cq8f7HExkjWSqjcej2Pl5E+jfJ/XvzHEi9/rYfFF+UzCSW1WT1IIfa4iaVMMrx6cuG5qRrqJQUlG lzR4g25zpifi6R+XK9GnDCEm989Rtv80PiV2psB2gxS+xJvo/jGCArowggK2AgEBMGIwXDELMAkG A1UEBhMCRlIxFzAVBgNVBAoTDkZyYW5jZSBUZWxlY29tMRMwEQYDVQQLEwpGVFJELUFzcGljMR8w HQYDVQQDExZGVFJEIEFDIG9wZXJhdGlvbm5lbGxlAgIpXDAJBgUrDgMCGgUAoIIBrjAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA0MjMxNDM4MjRaMCMGCSqGSIb3 DQEJBDEWBBTSz9yS2vhtdNot/l2edGf9h1YujTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAH BgUrDgMCGjAKBggqhkiG9w0CBTBxBgkrBgEEAYI3EAQxZDBiMFwxCzAJBgNVBAYTAkZSMRcwFQYD VQQKEw5GcmFuY2UgVGVsZWNvbTETMBEGA1UECxMKRlRSRC1Bc3BpYzEfMB0GA1UEAxMWRlRSRCBB QyBvcGVyYXRpb25uZWxsZQICKV0wcwYLKoZIhvcNAQkQAgsxZKBiMFwxCzAJBgNVBAYTAkZSMRcw FQYDVQQKEw5GcmFuY2UgVGVsZWNvbTETMBEGA1UECxMKRlRSRC1Bc3BpYzEfMB0GA1UEAxMWRlRS RCBBQyBvcGVyYXRpb25uZWxsZQICKV0wDQYJKoZIhvcNAQEBBQAEgYBaS+SINIPvDDUGL2ihpNBx sLPIOgHkpY74Dl91CGwy+LbvoBxeNP58T9M/xpAL5/rzoRnIYqoyy0Zbhm5ruWLhlE1I6MRheMdx UmUwDagRX0NghMZGDoOjXluCkHxG45lZGtpK535JMGxeI8dJMVYJWPtaa5gs9PBFGLeXg9WzXgAA AAAAAA== ------=_NextPart_000_0008_01C666F4.56CC70D0-- --===============0826799424== 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 --===============0826799424==-- From mpls-bounces@lists.ietf.org Sun Apr 23 17:30:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXm8E-0006vO-S1; Sun, 23 Apr 2006 17:28:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXm8D-0006vJ-BK for mpls@ietf.org; Sun, 23 Apr 2006 17:28:37 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXm8C-0002GK-24 for mpls@ietf.org; Sun, 23 Apr 2006 17:28:37 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 23 Apr 2006 14:28:36 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,150,1144047600"; d="scan'208"; a="26503394:sNHT24251756" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3NLSZvF001638; Sun, 23 Apr 2006 17:28:35 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 23 Apr 2006 17:28:35 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 23 Apr 2006 17:28:34 -0400 In-Reply-To: <444909C9.2070106@pi.se> References: <444909C9.2070106@pi.se> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7C3ECD61-8A6B-422A-8711-C1772C17FA03@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [mpls] working group document candidates Date: Sun, 23 Apr 2006 17:28:25 -0400 To: Loa Andersson X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 23 Apr 2006 21:28:34.0992 (UTC) FILETIME=[E080CB00:01C6671C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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: , Errors-To: mpls-bounces@lists.ietf.org On Apr 21, 2006, at 12:35 PM, Loa Andersson wrote: > All, > > the authors of the two following drafts has requested > that they are adopted as working group documents: > > draft-vasseur-mpls-number-0-bw-te-lsps-00 > draft-leroux-mpls-mp-ldp-reqs-03.txt > > draft-vasseur-... was discussed at the mpls wg meeting > in Dallas. We had a good support for the general idea, but > were uncertain how this should be handled document-wise. > The normal work flow would be that the mpls wg write a > requirement draft to the ospf and is-is working groups, > who each produce one spec for the extension for their > protocols. It has however been argued that this could be > addres in a single draft of less than a handful pages. > The (is-is, ospf and mpls) working group chairs and the > routing area ADs have there fore agreed that we can do > it in a single mpls working group document, which will > be sent to the other two working groups for review. > Yes (I'm an author) > draft-leroux-... was discussed at the same meeting, and > there were a good support in the room for adopting it > as a working group document. > Yes. JP. > Please respond to the mailing list whether you think > they should become wg docs or not. > > Loa and George > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sun Apr 23 18:04:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXmfR-000281-3X; Sun, 23 Apr 2006 18:02:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXmfP-00027w-Il for mpls@ietf.org; Sun, 23 Apr 2006 18:02:55 -0400 Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXmfP-0003jv-5m for mpls@ietf.org; Sun, 23 Apr 2006 18:02:55 -0400 Received: from nappa.corp.google.com (nappa.corp.google.com [172.24.0.4]) by smtp-out.google.com with ESMTP id k3NM2ovx024797; Sun, 23 Apr 2006 15:02:50 -0700 Received: from [10.1.5.123] (dmzdhcp5-123.corp.google.com [10.1.5.123]) (authenticated bits=0) by nappa.corp.google.com with ESMTP id k3NM2jW9027088 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 23 Apr 2006 15:02:46 -0700 In-Reply-To: <444909C9.2070106@pi.se> References: <444909C9.2070106@pi.se> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6ECB9DFA-8075-4FE6-9ECF-616CB3212F87@kumari.net> Content-Transfer-Encoding: 7bit From: Warren Kumari Subject: Re: [mpls] working group document candidates Date: Sun, 23 Apr 2006 15:02:44 -0700 To: Loa Andersson X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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: , Errors-To: mpls-bounces@lists.ietf.org On Apr 21, 2006, at 9:35 AM, Loa Andersson wrote: > All, > > the authors of the two following drafts has requested > that they are adopted as working group documents: > > draft-vasseur-mpls-number-0-bw-te-lsps-00 YES > draft-leroux-mpls-mp-ldp-reqs-03.txt > YES > draft-vasseur-... was discussed at the mpls wg meeting > in Dallas. We had a good support for the general idea, but > were uncertain how this should be handled document-wise. > The normal work flow would be that the mpls wg write a > requirement draft to the ospf and is-is working groups, > who each produce one spec for the extension for their > protocols. It has however been argued that this could be > addres in a single draft of less than a handful pages. > The (is-is, ospf and mpls) working group chairs and the > routing area ADs have there fore agreed that we can do > it in a single mpls working group document, which will > be sent to the other two working groups for review. > > draft-leroux-... was discussed at the same meeting, and > there were a good support in the room for adopting it > as a working group document. > > Please respond to the mailing list whether you think > they should become wg docs or not. > > Loa and George > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sun Apr 23 20:42:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXp89-000853-IN; Sun, 23 Apr 2006 20:40:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXp88-000829-6i for mpls@ietf.org; Sun, 23 Apr 2006 20:40:44 -0400 Received: from athena.kddi.com ([210.141.112.39] helo=UTMC1101.kddi.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXp87-00030j-QE for mpls@ietf.org; Sun, 23 Apr 2006 20:40:44 -0400 Received: from usjk1038 (unknown [10.5.16.70]) by UTMC1101.kddi.com (Postfix) with SMTP id 7DCC824D9 for ; Mon, 24 Apr 2006 09:40:35 +0900 (JST) Received: from UTMC1123.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 461A91B90 for ; Mon, 24 Apr 2006 09:40:26 +0900 (JST) Received: from UTMC1111.kddi.com (unknown [10.5.16.5]) by UTMC1123.kddi.com (Postfix) with ESMTP id 3763B1883 for ; Mon, 24 Apr 2006 09:40:26 +0900 (JST) Received: from [127.0.0.1] ([133.128.75.50] [133.128.75.50]) by post-ims.kddi.com with ESMTP; Mon, 24 Apr 2006 09:40:26 +0900 Date: Mon, 24 Apr 2006 09:40:13 +0900 From: Kenji Kumaki To: mpls@ietf.org Subject: Re: [mpls] working group document candidates In-Reply-To: <444909C9.2070106@pi.se> References: <444909C9.2070106@pi.se> Message-Id: <20060424093606.2A0E.KE-KUMAKI@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25 [ja] X-WAuditID: 0604240940260000125897 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org > > draft-vasseur-mpls-number-0-bw-te-lsps-00 Yes. > draft-leroux-mpls-mp-ldp-reqs-03.txt Yes. Thanks, Kenji > > draft-vasseur-... was discussed at the mpls wg meeting > in Dallas. We had a good support for the general idea, but > were uncertain how this should be handled document-wise. > The normal work flow would be that the mpls wg write a > requirement draft to the ospf and is-is working groups, > who each produce one spec for the extension for their > protocols. It has however been argued that this could be > addres in a single draft of less than a handful pages. > The (is-is, ospf and mpls) working group chairs and the > routing area ADs have there fore agreed that we can do > it in a single mpls working group document, which will > be sent to the other two working groups for review. > > draft-leroux-... was discussed at the same meeting, and > there were a good support in the room for adopting it > as a working group document. > > Please respond to the mailing list whether you think > they should become wg docs or not. > > Loa and George > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls -- Kenji Kumaki _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Apr 24 08:05:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXzmW-0000Ar-4i; Mon, 24 Apr 2006 08:03:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXzmU-0000Al-18 for mpls@ietf.org; Mon, 24 Apr 2006 08:03:06 -0400 Received: from mgw2.noc.ntt.com ([210.163.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXzmS-0008NU-FX for mpls@ietf.org; Mon, 24 Apr 2006 08:03:06 -0400 Received: from mop2.noc.ntt.com by mgw2.noc.ntt.com (NTT-Com MailSV) with ESMTP id k3OC32XC021796; Mon, 24 Apr 2006 21:03:02 +0900 (JST) Received: from mip3.noc.ntt.com (mvi1.noc.ntt.com) by mop2.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0IY800KR76T16X@ntt.com>; Mon, 24 Apr 2006 21:03:02 +0900 (JST) Date: Mon, 24 Apr 2006 21:03:01 +0900 From: "Yuji KAMITE" Subject: RE: [mpls] working group document candidates In-reply-to: <444909C9.2070106@pi.se> To: "'Loa Andersson'" , mpls@ietf.org Message-id: <0IY800L5D6T1BJ@ntt.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Thread-index: AcZlYfv0rXvtPi/VRYSdCbcdI6/q9ACM2/mQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org > the authors of the two following drafts has requested that > they are adopted as working group documents: > > draft-vasseur-mpls-number-0-bw-te-lsps-00 Yes. > draft-leroux-mpls-mp-ldp-reqs-03.txt Yes. Regards, -Yuji _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Apr 24 09:08:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY0le-0001WB-83; Mon, 24 Apr 2006 09:06:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY0ld-0001W6-LU for mpls@ietf.org; Mon, 24 Apr 2006 09:06:17 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY0ld-0002gD-65 for mpls@ietf.org; Mon, 24 Apr 2006 09:06:17 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 24 Apr 2006 06:06:17 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,151,1144047600"; d="scan'208"; a="26534809:sNHT27020832" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3OD6GTL020088; Mon, 24 Apr 2006 09:06:16 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 09:06:16 -0400 Received: from [10.83.15.50] ([10.83.15.50]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 09:06:15 -0400 In-Reply-To: <4449589E.8020808@pi.se> References: <4449589E.8020808@pi.se> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [mpls] consolidated response to Q12/15 on T-MPLS Date: Mon, 24 Apr 2006 09:06:27 -0400 To: Loa Andersson X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 24 Apr 2006 13:06:15.0621 (UTC) FILETIME=[DE737F50:01C6679F] X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 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: , Errors-To: mpls-bounces@lists.ietf.org Loa, You see to have missed one of the comments which came from at least 2 of the comments received during the WG meeting and afterwards. In particular, you do not ask that the "T-MPLS" name remove "MPLS" from the name. This probably best falls under the "T-MPLS trademark" subsection below. I suggest you simply change the subheading to "Specification Naming" and add a paragraph explaining the above regarding name change, and also include the trademark discussion. --Tom > Working Group, > > this is the consolidated list of concerns we've sent to the Q12/15. > > Note that we will further refine this list and send our formal > response May 17th. Further comments are welcome. > > Loa and George > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > > Areas of concerns on Transport MPLS from the MPLS working group > =============================================================== > > To: Q12/15 > > At this point, members of the IETF are expressing their concerns on > Transport-MPLS on the MPLS and CCAMP mailing lists. We are working > to collect and evaluate these and come to a consensus response to > your liaison. > > The included somewhat consolidated list is still preliminary, e.g. > it still lacks in structure. > > However we would like to alert you that our preliminary judgment is > that some of the issues are of a serious nature. At least PHP, > signaling protocol and reserved labels are of this serious nautre. > > More careful reading of the documents reveals that there is an > appendix in G.8110.1 that addresses MPLS pseudowires. This document > should also have been liaised to the PWE3 working group in the > IETF as well. This appendix references draft-pan-pwe3-over-sub-ip-01 > this draft is no longer active. > > Requirements > ------------ > We have not seen any requirements specification for T-MPLS. > > Penultimate Hop Popping (PHP) > ----------------------------- > We discussed this several times with different ITU-T SGs and > Questions, we've agreed that the right way of stating this is > that it is "mandatory to implement, optional to use" PHP. We > would appreciate if the T-MPLS could adopt the same text. > > Note: We also think that it is a misconception to think that > non-PHP is less complex than PHP. > > Signaling protocol > ------------------ > It is nowhere specified which signaling protocol will be used for > for T-MPLS. > > It is also unclear if traffic engineering functionality is required. > > Note: if traffic engineering functionality is required, there > is a strong recommendation from the IETF to use RSVP-TE. > > Note 2: If this effort leads to requirements on changes in the IETF > signaling protocols this should be handled according to > draft-andersson-rtg-gmpls-change-02. > > Non-merging > ----------- > T-MPLS states that merging of LSPs is not used. > > Merging was introduced to address the problem with a high number > of LSPs in the core. How is the n-squared problem addressed in > T-MPLS? > > Note: It is not a given that non-merging of LSPs from a protocol > procedural or processing point of view necessarily is less > complex than a merging variant. > > Reserved labels > --------------- > MPLS reserves label values 0-15 for special use. T-MPLS at one point > also intended to reserve values 16-31 for similar use. It has been > pointed out that this will make all existing MPLS implementations > incompatible with T-MPLS. > > Labels 16-31 are said to be for further study. Some comments to the > MPLS mailing list indicates that there is no plans to assign any > semantics to labels 16-31. What is the reason to mention them if > this is the case. > > In particular does the statement imply that these label values > should be > reserved. It is our opinion that: > > 1) If they are reserved then T-MPLS is incompatible with MPLS in a > number of scenarios. It also would mean that T-MPLS is not a > subset > of MPLS (over and above the issue cited below). > > 2) If they are not reserved, reserving them in the future would cause > intolerable deployment difficulties. > > In conclusion you should either say the labels are reserved and > clearly > declare that T-MPLS is not compatible with MPLS or remove the FFS text > entirely. > > > True subset of MPLS > ------------------- > It has been claimed that T-MPLS is a true subset of MPLS, yet the > Y.1711 seems to be a part of T-MPLS. Y.1711 is not part of MPLS. > > If what is wanted is really a subset of MPLS, we believe several > aspects > has to be made clear > - the exact relationship to MPLS > - that enough functionality is there to make interoperability with > MPLS possible > - the MPLS OAM specification in RFC4377 has to be addressed > > There is previous art in defining similar "subsets" of MPLS, > e.g. "draft-loa-mpls-cap-set-01.txt" and > "draft-rosen-mpls-profiles-00.txt"; these efforts did not go very far > since it was not obvious that they solved a real problem. > In general it would be good to have a clear problem statement for > T-MPLS. > > T-MPLS trademark > ---------------- > It has been brought to our notice that one of the parties active > in developing the T-MPLS has a trademark on "T-MPLS". We don't > know if this is a serious matter. Our postion on this is that > IETF owns MPLS, though we never tried to trademark it, we are for > open standards, and would see any attempt to use the MPLS and > GMPLS technologies by means of trademarking as hostile. > > Interoperability at the MPLS / T-MPLS interface > ----------------------------------------------- > Several of the issues we have are for the interoperability between > a T-MPLS device and an MPLS device. We can't see that these issues > are discussed anywhere. We believe that these issues need to be > addressed at least to make sure that there is no interoperability > problems. > > Per platform or per interface labels > +++++++++++++++++++++++++++++++++++ > For a local link repair it is crucial whether the box you are > talking to uses a per platform or per link label space. > > Note that if T-MPLS were to reserve labels 16-31 > then T-MPLS cannot have a per platform label space if the platform > also > has mpls interfaces. These labels are *NOT* reserved by MPLS and are > extremely likely to be allocated. > > I would also like it made clear as to whether they envision T-MPLS > diverging on the interpretation of the EOS bit and the QoS/Exp bits. > > Global labels > +++++++++++++ > T-MPLS renames per platform labels "global labels", since global is > an IETF term used to signify domain wide labels, is there a > rationale for this renaming of platform to global? T-MPLS should > align with the MPLS terminology. > > TTL management and LSP tunnels > ++++++++++++++++++++++++++++++ > RFC3443 describes how TTLs are handled in LSPs tunnels. The G.8110.1 > state that it only supports RFC3443 for pipes and short pipes only. > This is a potential incompatibility with MPLS over the interface > between MPLS and T-MPLS networks. > > Interoperability over interface between MPLS and T-MPLS networks > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Some of the MPLS applications has been designed with certain MPLS > features taken for granted, e.g.: > > - pseudowires assumes per platform labels > - VPN assumes PHP > - etc > > for these applications to work as before a T-MPLS box will need to > have two types of interfaces. One interface that works as specified > in T-MPLS and another interface that works as specified in MPLS. > The T-MPLS needs to translate between the T-MPLS and the MPLS > environment since this is not in the MPLS specifications from start. > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Apr 24 10:14:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY1ng-0007tf-Q4; Mon, 24 Apr 2006 10:12:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY1nf-0007ta-E6 for mpls@ietf.org; Mon, 24 Apr 2006 10:12:27 -0400 Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY1ne-0005w1-49 for mpls@ietf.org; Mon, 24 Apr 2006 10:12:27 -0400 Received: from dhcp-8-79.ripemtg.ripe.net ([193.0.8.79]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1FY1nV-0007Wy-Ct; Mon, 24 Apr 2006 16:12:21 +0200 Message-ID: <444CDC83.3030803@pi.se> Date: Mon, 24 Apr 2006 16:11:15 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Subject: Re: [mpls] wg last call draft-ietf-mpls-over-l2tpv3-01 References: <443A5EC4.9040801@pi.se> In-Reply-To: <443A5EC4.9040801@pi.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 TW_TP BODY: Odd Letter Triples with TP X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org All, this closes the wg last call on draft-ietf-mpls-over-l2tpv3-01. We've seen no comments, draw the conclusion that this is aggrement. Could the authors do any last minute changes (if) required and notify the working group co-chairs when we are ready to request publication. Loa and George Loa Andersson wrote: > Working Group, > > this mail initiates a two week working last call on: > > draft-ietf-mpls-over-l2tpv3-01 > > Please send your comment to the working mailing list or directly > to the working group co-chairs. > > The working group last call ends eob April 24. > > /Loa > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Apr 24 10:39:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY2CA-0000OK-Fr; Mon, 24 Apr 2006 10:37:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY2C8-0000O9-Ts for mpls@ietf.org; Mon, 24 Apr 2006 10:37:44 -0400 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY2C8-0007jW-Dz for mpls@ietf.org; Mon, 24 Apr 2006 10:37:44 -0400 Received: from usruamalisl.mail.com (usruamalisl.tellabs-west.tellabsinc.net[193.0.8.143]) by comcast.net (rwcrmhc12) with SMTP id <20060424143741m1200dvpd6e>; Mon, 24 Apr 2006 14:37:42 +0000 Message-Id: <7.0.1.0.2.20060424101520.0526e898@comcast.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 24 Apr 2006 10:21:04 -0400 To: "Thomas D. Nadeau" From: "Andrew G. Malis" Subject: Re: [mpls] consolidated response to Q12/15 on T-MPLS In-Reply-To: References: <4449589E.8020808@pi.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.0 (++) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 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: , Errors-To: mpls-bounces@lists.ietf.org Tom, I don't know if we have consensus that we want the ITU-T to remove "MPLS" from "T-MPLS". The issue is that we don't want anyone to attempt to trademark any terms that include the letters "MPLS" in that order, whether it's the ITU or a private company. Cheers, Andy ---------- At 4/24/2006 09:06 -0400, Thomas D. Nadeau wrote: > Loa, > > You see to have missed one of the comments which >came from at least 2 of the comments received during >the WG meeting and afterwards. In particular, you >do not ask that the "T-MPLS" name remove "MPLS" from >the name. This probably best falls under the >"T-MPLS trademark" subsection below. I suggest you >simply change the subheading to "Specification Naming" >and add a paragraph explaining the above regarding >name change, and also include the trademark >discussion. > > --Tom > > >>Working Group, >> >>this is the consolidated list of concerns we've sent to the Q12/15. >> >>Note that we will further refine this list and send our formal >>response May 17th. Further comments are welcome. >> >>Loa and George >> >>-- >>Loa Andersson >> >>Principal Networking Architect >>Acreo AB phone: +46 8 632 77 14 >>Isafjordsgatan 22 mobile: +46 739 81 21 64 >>Kista, Sweden email: loa.andersson@acreo.se >> loa@pi.se >> >>Areas of concerns on Transport MPLS from the MPLS working group >>=============================================================== >> >>To: Q12/15 >> >>At this point, members of the IETF are expressing their concerns on >>Transport-MPLS on the MPLS and CCAMP mailing lists. We are working >>to collect and evaluate these and come to a consensus response to >>your liaison. >> >>The included somewhat consolidated list is still preliminary, e.g. >>it still lacks in structure. >> >>However we would like to alert you that our preliminary judgment is >>that some of the issues are of a serious nature. At least PHP, >>signaling protocol and reserved labels are of this serious nautre. >> >>More careful reading of the documents reveals that there is an >>appendix in G.8110.1 that addresses MPLS pseudowires. This document >>should also have been liaised to the PWE3 working group in the >>IETF as well. This appendix references draft-pan-pwe3-over-sub-ip-01 >>this draft is no longer active. >> >>Requirements >>------------ >>We have not seen any requirements specification for T-MPLS. >> >>Penultimate Hop Popping (PHP) >>----------------------------- >>We discussed this several times with different ITU-T SGs and >>Questions, we've agreed that the right way of stating this is >>that it is "mandatory to implement, optional to use" PHP. We >>would appreciate if the T-MPLS could adopt the same text. >> >>Note: We also think that it is a misconception to think that >>non-PHP is less complex than PHP. >> >>Signaling protocol >>------------------ >>It is nowhere specified which signaling protocol will be used for >>for T-MPLS. >> >>It is also unclear if traffic engineering functionality is required. >> >>Note: if traffic engineering functionality is required, there >>is a strong recommendation from the IETF to use RSVP-TE. >> >>Note 2: If this effort leads to requirements on changes in the IETF >>signaling protocols this should be handled according to >>draft-andersson-rtg-gmpls-change-02. >> >>Non-merging >>----------- >>T-MPLS states that merging of LSPs is not used. >> >>Merging was introduced to address the problem with a high number >>of LSPs in the core. How is the n-squared problem addressed in >>T-MPLS? >> >>Note: It is not a given that non-merging of LSPs from a protocol >>procedural or processing point of view necessarily is less >>complex than a merging variant. >> >>Reserved labels >>--------------- >>MPLS reserves label values 0-15 for special use. T-MPLS at one point >>also intended to reserve values 16-31 for similar use. It has been >>pointed out that this will make all existing MPLS implementations >>incompatible with T-MPLS. >> >>Labels 16-31 are said to be for further study. Some comments to the >>MPLS mailing list indicates that there is no plans to assign any >>semantics to labels 16-31. What is the reason to mention them if >>this is the case. >> >>In particular does the statement imply that these label values >>should be >>reserved. It is our opinion that: >> >>1) If they are reserved then T-MPLS is incompatible with MPLS in a >> number of scenarios. It also would mean that T-MPLS is not a >>subset >> of MPLS (over and above the issue cited below). >> >>2) If they are not reserved, reserving them in the future would cause >> intolerable deployment difficulties. >> >>In conclusion you should either say the labels are reserved and >>clearly >>declare that T-MPLS is not compatible with MPLS or remove the FFS text >>entirely. >> >> >>True subset of MPLS >>------------------- >>It has been claimed that T-MPLS is a true subset of MPLS, yet the >>Y.1711 seems to be a part of T-MPLS. Y.1711 is not part of MPLS. >> >>If what is wanted is really a subset of MPLS, we believe several >>aspects >>has to be made clear >>- the exact relationship to MPLS >>- that enough functionality is there to make interoperability with >> MPLS possible >>- the MPLS OAM specification in RFC4377 has to be addressed >> >>There is previous art in defining similar "subsets" of MPLS, >>e.g. "draft-loa-mpls-cap-set-01.txt" and >>"draft-rosen-mpls-profiles-00.txt"; these efforts did not go very far >>since it was not obvious that they solved a real problem. >>In general it would be good to have a clear problem statement for >>T-MPLS. >> >>T-MPLS trademark >>---------------- >>It has been brought to our notice that one of the parties active >>in developing the T-MPLS has a trademark on "T-MPLS". We don't >>know if this is a serious matter. Our postion on this is that >>IETF owns MPLS, though we never tried to trademark it, we are for >>open standards, and would see any attempt to use the MPLS and >>GMPLS technologies by means of trademarking as hostile. >> >>Interoperability at the MPLS / T-MPLS interface >>----------------------------------------------- >>Several of the issues we have are for the interoperability between >>a T-MPLS device and an MPLS device. We can't see that these issues >>are discussed anywhere. We believe that these issues need to be >>addressed at least to make sure that there is no interoperability >>problems. >> >>Per platform or per interface labels >>+++++++++++++++++++++++++++++++++++ >>For a local link repair it is crucial whether the box you are >>talking to uses a per platform or per link label space. >> >>Note that if T-MPLS were to reserve labels 16-31 >>then T-MPLS cannot have a per platform label space if the platform >>also >>has mpls interfaces. These labels are *NOT* reserved by MPLS and are >>extremely likely to be allocated. >> >>I would also like it made clear as to whether they envision T-MPLS >>diverging on the interpretation of the EOS bit and the QoS/Exp bits. >> >>Global labels >>+++++++++++++ >>T-MPLS renames per platform labels "global labels", since global is >>an IETF term used to signify domain wide labels, is there a >>rationale for this renaming of platform to global? T-MPLS should >>align with the MPLS terminology. >> >>TTL management and LSP tunnels >>++++++++++++++++++++++++++++++ >>RFC3443 describes how TTLs are handled in LSPs tunnels. The G.8110.1 >>state that it only supports RFC3443 for pipes and short pipes only. >>This is a potential incompatibility with MPLS over the interface >>between MPLS and T-MPLS networks. >> >>Interoperability over interface between MPLS and T-MPLS networks >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>Some of the MPLS applications has been designed with certain MPLS >>features taken for granted, e.g.: >> >>- pseudowires assumes per platform labels >>- VPN assumes PHP >>- etc >> >>for these applications to work as before a T-MPLS box will need to >>have two types of interfaces. One interface that works as specified >>in T-MPLS and another interface that works as specified in MPLS. >>The T-MPLS needs to translate between the T-MPLS and the MPLS >>environment since this is not in the MPLS specifications from start. >> >> >>_______________________________________________ >>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@lists.ietf.org Mon Apr 24 11:15:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY2kQ-0004Sg-OQ; Mon, 24 Apr 2006 11:13:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY2kO-0004Sb-Tg for mpls@ietf.org; Mon, 24 Apr 2006 11:13:08 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY2kN-0001IA-83 for mpls@ietf.org; Mon, 24 Apr 2006 11:13:08 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 24 Apr 2006 08:13:06 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,152,1144047600"; d="scan'208"; a="26550667:sNHT29991902" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3OFD5TL022031; Mon, 24 Apr 2006 11:13:06 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 11:13:05 -0400 Received: from [10.83.15.50] ([10.83.15.50]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 11:13:05 -0400 In-Reply-To: <7.0.1.0.2.20060424101520.0526e898@comcast.net> References: <4449589E.8020808@pi.se> <7.0.1.0.2.20060424101520.0526e898@comcast.net> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9373EA68-01ED-417E-BD87-FA079E6DC08F@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [mpls] consolidated response to Q12/15 on T-MPLS Date: Mon, 24 Apr 2006 11:13:17 -0400 To: "Andrew G. Malis" X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 24 Apr 2006 15:13:05.0469 (UTC) FILETIME=[964626D0:01C667B1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a 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: , Errors-To: mpls-bounces@lists.ietf.org There were no comments to the contrary as far as I can tell. That is, no one commented on the list or at the meeting that leaving MPLS in the name as okay. I did however, hear at least 3 responses to explicitly strike MPLS from the name. --Tom > Tom, > > I don't know if we have consensus that we want the ITU-T to remove > "MPLS" from "T-MPLS". The issue is that we don't want anyone to > attempt to trademark any terms that include the letters "MPLS" in > that order, whether it's the ITU or a private company. > > Cheers, > Andy > > ---------- > > At 4/24/2006 09:06 -0400, Thomas D. Nadeau wrote: > >> Loa, >> >> You see to have missed one of the comments which >> came from at least 2 of the comments received during >> the WG meeting and afterwards. In particular, you >> do not ask that the "T-MPLS" name remove "MPLS" from >> the name. This probably best falls under the >> "T-MPLS trademark" subsection below. I suggest you >> simply change the subheading to "Specification Naming" >> and add a paragraph explaining the above regarding >> name change, and also include the trademark >> discussion. >> >> --Tom >> >> >>> Working Group, >>> >>> this is the consolidated list of concerns we've sent to the Q12/15. >>> >>> Note that we will further refine this list and send our formal >>> response May 17th. Further comments are welcome. >>> >>> Loa and George >>> >>> -- >>> Loa Andersson >>> >>> Principal Networking Architect >>> Acreo AB phone: +46 8 632 77 14 >>> Isafjordsgatan 22 mobile: +46 739 81 21 64 >>> Kista, Sweden email: loa.andersson@acreo.se >>> loa@pi.se >>> >>> Areas of concerns on Transport MPLS from the MPLS working group >>> =============================================================== >>> >>> To: Q12/15 >>> >>> At this point, members of the IETF are expressing their concerns on >>> Transport-MPLS on the MPLS and CCAMP mailing lists. We are working >>> to collect and evaluate these and come to a consensus response to >>> your liaison. >>> >>> The included somewhat consolidated list is still preliminary, e.g. >>> it still lacks in structure. >>> >>> However we would like to alert you that our preliminary judgment is >>> that some of the issues are of a serious nature. At least PHP, >>> signaling protocol and reserved labels are of this serious nautre. >>> >>> More careful reading of the documents reveals that there is an >>> appendix in G.8110.1 that addresses MPLS pseudowires. This document >>> should also have been liaised to the PWE3 working group in the >>> IETF as well. This appendix references draft-pan-pwe3-over-sub-ip-01 >>> this draft is no longer active. >>> >>> Requirements >>> ------------ >>> We have not seen any requirements specification for T-MPLS. >>> >>> Penultimate Hop Popping (PHP) >>> ----------------------------- >>> We discussed this several times with different ITU-T SGs and >>> Questions, we've agreed that the right way of stating this is >>> that it is "mandatory to implement, optional to use" PHP. We >>> would appreciate if the T-MPLS could adopt the same text. >>> >>> Note: We also think that it is a misconception to think that >>> non-PHP is less complex than PHP. >>> >>> Signaling protocol >>> ------------------ >>> It is nowhere specified which signaling protocol will be used for >>> for T-MPLS. >>> >>> It is also unclear if traffic engineering functionality is required. >>> >>> Note: if traffic engineering functionality is required, there >>> is a strong recommendation from the IETF to use RSVP-TE. >>> >>> Note 2: If this effort leads to requirements on changes in the IETF >>> signaling protocols this should be handled according to >>> draft-andersson-rtg-gmpls-change-02. >>> >>> Non-merging >>> ----------- >>> T-MPLS states that merging of LSPs is not used. >>> >>> Merging was introduced to address the problem with a high number >>> of LSPs in the core. How is the n-squared problem addressed in >>> T-MPLS? >>> >>> Note: It is not a given that non-merging of LSPs from a protocol >>> procedural or processing point of view necessarily is less >>> complex than a merging variant. >>> >>> Reserved labels >>> --------------- >>> MPLS reserves label values 0-15 for special use. T-MPLS at one point >>> also intended to reserve values 16-31 for similar use. It has been >>> pointed out that this will make all existing MPLS implementations >>> incompatible with T-MPLS. >>> >>> Labels 16-31 are said to be for further study. Some comments to the >>> MPLS mailing list indicates that there is no plans to assign any >>> semantics to labels 16-31. What is the reason to mention them if >>> this is the case. >>> >>> In particular does the statement imply that these label values >>> should be >>> reserved. It is our opinion that: >>> >>> 1) If they are reserved then T-MPLS is incompatible with MPLS in a >>> number of scenarios. It also would mean that T-MPLS is not a >>> subset >>> of MPLS (over and above the issue cited below). >>> >>> 2) If they are not reserved, reserving them in the future would >>> cause >>> intolerable deployment difficulties. >>> >>> In conclusion you should either say the labels are reserved and >>> clearly >>> declare that T-MPLS is not compatible with MPLS or remove the FFS >>> text >>> entirely. >>> >>> >>> True subset of MPLS >>> ------------------- >>> It has been claimed that T-MPLS is a true subset of MPLS, yet the >>> Y.1711 seems to be a part of T-MPLS. Y.1711 is not part of MPLS. >>> >>> If what is wanted is really a subset of MPLS, we believe several >>> aspects >>> has to be made clear >>> - the exact relationship to MPLS >>> - that enough functionality is there to make interoperability with >>> MPLS possible >>> - the MPLS OAM specification in RFC4377 has to be addressed >>> >>> There is previous art in defining similar "subsets" of MPLS, >>> e.g. "draft-loa-mpls-cap-set-01.txt" and >>> "draft-rosen-mpls-profiles-00.txt"; these efforts did not go very >>> far >>> since it was not obvious that they solved a real problem. >>> In general it would be good to have a clear problem statement for >>> T-MPLS. >>> >>> T-MPLS trademark >>> ---------------- >>> It has been brought to our notice that one of the parties active >>> in developing the T-MPLS has a trademark on "T-MPLS". We don't >>> know if this is a serious matter. Our postion on this is that >>> IETF owns MPLS, though we never tried to trademark it, we are for >>> open standards, and would see any attempt to use the MPLS and >>> GMPLS technologies by means of trademarking as hostile. >>> >>> Interoperability at the MPLS / T-MPLS interface >>> ----------------------------------------------- >>> Several of the issues we have are for the interoperability between >>> a T-MPLS device and an MPLS device. We can't see that these issues >>> are discussed anywhere. We believe that these issues need to be >>> addressed at least to make sure that there is no interoperability >>> problems. >>> >>> Per platform or per interface labels >>> +++++++++++++++++++++++++++++++++++ >>> For a local link repair it is crucial whether the box you are >>> talking to uses a per platform or per link label space. >>> >>> Note that if T-MPLS were to reserve labels 16-31 >>> then T-MPLS cannot have a per platform label space if the platform >>> also >>> has mpls interfaces. These labels are *NOT* reserved by MPLS and >>> are >>> extremely likely to be allocated. >>> >>> I would also like it made clear as to whether they envision T-MPLS >>> diverging on the interpretation of the EOS bit and the QoS/Exp bits. >>> >>> Global labels >>> +++++++++++++ >>> T-MPLS renames per platform labels "global labels", since global is >>> an IETF term used to signify domain wide labels, is there a >>> rationale for this renaming of platform to global? T-MPLS should >>> align with the MPLS terminology. >>> >>> TTL management and LSP tunnels >>> ++++++++++++++++++++++++++++++ >>> RFC3443 describes how TTLs are handled in LSPs tunnels. The G.8110.1 >>> state that it only supports RFC3443 for pipes and short pipes only. >>> This is a potential incompatibility with MPLS over the interface >>> between MPLS and T-MPLS networks. >>> >>> Interoperability over interface between MPLS and T-MPLS networks >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> Some of the MPLS applications has been designed with certain MPLS >>> features taken for granted, e.g.: >>> >>> - pseudowires assumes per platform labels >>> - VPN assumes PHP >>> - etc >>> >>> for these applications to work as before a T-MPLS box will need to >>> have two types of interfaces. One interface that works as specified >>> in T-MPLS and another interface that works as specified in MPLS. >>> The T-MPLS needs to translate between the T-MPLS and the MPLS >>> environment since this is not in the MPLS specifications from start. >>> >>> >>> _______________________________________________ >>> 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 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Apr 24 11:22:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY2rg-0006mh-M7; Mon, 24 Apr 2006 11:20:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY2re-0006mc-Js for mpls@lists.ietf.org; Mon, 24 Apr 2006 11:20:38 -0400 Received: from pproxy.gmail.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY2rd-0001hv-Av for mpls@lists.ietf.org; Mon, 24 Apr 2006 11:20:38 -0400 Received: by pproxy.gmail.com with SMTP id t32so1034072pyc for ; Mon, 24 Apr 2006 08:20:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=kidjKL8E1Dty7yv78iR1asOCIanKevbDRYl6v8JYO7ws7UYROFLAJ8EhhlWVFdOo1Tg1ZrNYUNX7LGzQNfUhttaBB3vvTrikXEV5bX4GTXyB5GKszA5iw8funroyQBlbG9EkmmZrzKEhGROyHbiBTt67GAs7Cbzx+JdZMmher2A= Received: by 10.35.100.6 with SMTP id c6mr1035725pym; Mon, 24 Apr 2006 08:20:34 -0700 (PDT) Received: by 10.35.26.7 with HTTP; Mon, 24 Apr 2006 08:20:34 -0700 (PDT) Message-ID: Date: Mon, 24 Apr 2006 20:20:34 +0500 From: "Fahad Dogar" To: mpls@lists.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [mpls] GMPLS support for Ethernet switching (also mailed to ccamp list) X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi all, I have few questions related to the draft on GMPLS support for Ethernet switching by D.Papadimitriou et al.: i) The draft discusses that connection oriented ethernet is suitable for metro and core networks where ethernet is used for transport. I am not too clear on the architecture in which ethernet LSPs would be used. Are we considering point to point type ethernet connections between switches/routers i.e. where the bandwidth is not shared. Example: Two peer routers connected through an ethernet interface, so effectively complete bandwidth is available. Or are we talking about multiple switches in a GMPLS enabled cloud that are part of the SAME LAN and bandwidth is shared. I am not sure how bandwidth reservations would be done in this sceneario. ii) Please correct me if I am wrong but it seems that the traffic engineering benefits of GMPLS support for Ethernet are also available in Ethernet over MPLS. (I am considering that connection oriented Ethernet is used in metro/core networks only). However, by providing GMPLS support for Ethernet we are able to do away with IP/MPLS layer and thus we can have an all Ethernet network (with only ethernet switches). Is this the primary reason for using GMPLS support for Ethernet rather than Ethernet over MPLS? Can someone comment on this? iii) The draft discusses various options for ethernet label, all of which seem to require modification in the forwarding plane of Ethernet? Is this something that can implemented easily i.e. change in forwarding plane? Why can't we consider MAC address or VLAN tag as the label? Thanks in advance, Fahad _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Apr 24 11:29:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY2yd-00012p-6E; Mon, 24 Apr 2006 11:27:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY2yb-00012j-Qi for mpls@ietf.org; Mon, 24 Apr 2006 11:27:49 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY2ya-000207-JT for mpls@ietf.org; Mon, 24 Apr 2006 11:27:49 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 24 Apr 2006 11:27:48 -0400 X-IronPort-AV: i="4.04,152,1144036800"; d="scan'208"; a="87094137:sNHT30500720" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3OFRkTX025841; Mon, 24 Apr 2006 11:27:48 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 11:27:48 -0400 Received: from [10.86.242.55] ([10.86.242.55]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 11:27:47 -0400 Message-ID: <444CEE72.2000604@employees.org> Date: Mon, 24 Apr 2006 11:27:46 -0400 From: Scott W Brim User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Thomas D. Nadeau" Subject: Re: [mpls] consolidated response to Q12/15 on T-MPLS References: <4449589E.8020808@pi.se> <7.0.1.0.2.20060424101520.0526e898@comcast.net> <9373EA68-01ED-417E-BD87-FA079E6DC08F@cisco.com> In-Reply-To: <9373EA68-01ED-417E-BD87-FA079E6DC08F@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2006 15:27:47.0512 (UTC) FILETIME=[A4033B80:01C667B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org On 04/24/2006 11:13 AM, Thomas D. Nadeau allegedly wrote: > > There were no comments to the contrary as > far as I can tell. That is, no one commented > on the list or at the meeting that leaving > MPLS in the name as okay. I did however, hear > at least 3 responses to explicitly strike MPLS > from the name. I spoke against insisting on renaming, although maybe not on this list. So far the ITU-T's stated intention is to define a subset of MPLS, not to create something new. See their liaison: "The intent of these Recommendations is not to change MPLS but rather to identify a subset of existing MPLS necessary and sufficient to provide connection-oriented packet transport." There is no need or advantage to asking them to take "MPLS" out of their name until it is clearly no longer a subset. That will depend on how the current discussion goes. Let's not create the future we are concerned about. You bring up trademark. That's unrelated -- it's not the IETF and the ITU, it's between the IETF and whoever trademarked something with "MPLS" in it. Thanks ... Scott _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Apr 24 17:44:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8oe-00047O-0q; Mon, 24 Apr 2006 17:41:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8od-00045l-4H for mpls@ietf.org; Mon, 24 Apr 2006 17:41:55 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FY8ob-0004lT-PA for mpls@ietf.org; Mon, 24 Apr 2006 17:41:55 -0400 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-3.tower-120.messagelabs.com!1145914737!10803720!32 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 6595 invoked from network); 24 Apr 2006 21:41:50 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-3.tower-120.messagelabs.com with SMTP; 24 Apr 2006 21:41:50 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh3i.attrh.att.com (7.2.052) id 444BA5FE0002C154; Mon, 24 Apr 2006 17:41:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] consolidated response to Q12/15 on T-MPLS Date: Mon, 24 Apr 2006 16:41:49 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF0BF27B71@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <444B58E9.3050801@employees.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] consolidated response to Q12/15 on T-MPLS Thread-Index: AcZmwhhFcDbL9nphRtC/6+Si+HeSHwA6s/8g From: "Brungard, Deborah A, ALABS" To: "Scott W Brim" X-Spam-Score: 0.0 (/) 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: , Errors-To: mpls-bounces@lists.ietf.org Also client processing is different - T-MPLS has T-MPLS client-specific processes (Section 7 lists clients as IP, Ethernet, ATM, MPLS, T-MPLS). The new amendment to G.8010 (unfortunately not liaisoned) clearly shows two different processes (e.g. Ethernet/MPLS, Ethernet/T-MPLS).=20 Having here a weekend of rainy weather with time to read, T-MPLS features are listed in section 6.1, including: - supports bidirectional LSPs - supports control channel separation - supports only Y.1720 protection switching (ITU's 1+1 scheme based on sequence numbers) To me, it "looks" somewhat like GMPLS (and similar application - transport equipment), though it's labeled MPLS, and supports different functionality than MPLS or GMPLS. The control plane is tbd. It is difficult to comment if it is a subset of MPLS (or GMPLS) - without a clear statement of the requirements and understanding of the modifications to the "superset". Especially interesting will be e-2-e operations when Figure 5's "foreign TMPLS network" is present in a not-so-clean scenario of cloudy networks. Deborah -----Original Message----- From: Scott W Brim [mailto:swb@employees.org]=20 Sent: Sunday, April 23, 2006 6:37 AM To: Andrew G. Malis Cc: mpls@ietf.org Subject: Re: [mpls] consolidated response to Q12/15 on T-MPLS On 04/23/2006 03:36 AM, Andrew G. Malis allegedly wrote: > So, I guess we need to know whether or not the T-MPLS equipment will do > any MPLS-layer processing of the packets, or simply transparently > transport them without inspection or change, and what signaling (if any) > would be used across this interface. That's the plan as far as I know, but I don't think it has been completely spelled out. Another interesting scenario is where a device has both "full" MPLS and T-MPLS LSPs on the same interface. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Apr 24 18:06:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY9Al-0003Sm-Fa; Mon, 24 Apr 2006 18:04:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY9Ak-0003Sa-1k; Mon, 24 Apr 2006 18:04:46 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY9Aj-00064r-MZ; Mon, 24 Apr 2006 18:04:46 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k3OM4jN6015203; Mon, 24 Apr 2006 15:04:45 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k3OM4jhS015202; Mon, 24 Apr 2006 15:04:45 -0700 Date: Mon, 24 Apr 2006 15:04:45 -0700 Message-Id: <200604242204.k3OM4jhS015202@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: mpls@lists.ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 4461 on Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs) 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: , Errors-To: mpls-bounces@lists.ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4461 Title: Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs) Author: S. Yasukawa, Ed. Status: Informational Date: April 2006 Mailbox: yasukawa.seisho@lab.ntt.co.jp Pages: 30 Characters: 64542 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-p2mp-sig-requirement-04.txt URL: http://www.rfc-editor.org/rfc/rfc4461.txt This document presents a set of requirements for the establishment and maintenance of Point-to-Multipoint (P2MP) Traffic-Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). There is no intent to specify solution-specific details or application-specific requirements in this document. The requirements presented in this document not only apply to packet-switched networks under the control of MPLS protocols, but also encompass the requirements of Layer Two Switching (L2SC), Time Division Multiplexing (TDM), lambda, and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document must attempt to be equally applicable to MPLS and GMPLS. This memo provides information for the Internet community. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 25 04:29:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYIsw-0000qe-5C; Tue, 25 Apr 2006 04:27:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYIsu-0000qP-OY for mpls@ietf.org; Tue, 25 Apr 2006 04:27:00 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYIsp-0000Fm-Cb for mpls@ietf.org; Tue, 25 Apr 2006 04:27:00 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IY900KJ5RFW3U@szxga01-in.huawei.com> for mpls@ietf.org; Tue, 25 Apr 2006 16:26:20 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IY900KFSRFWBN@szxga01-in.huawei.com> for mpls@ietf.org; Tue, 25 Apr 2006 16:26:20 +0800 (CST) Received: from c50408 ([10.110.115.29]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IY900IBNS938V@szxml01-in.huawei.com> for mpls@ietf.org; Tue, 25 Apr 2006 16:43:52 +0800 (CST) Date: Tue, 25 Apr 2006 16:25:58 +0800 From: Cao Wei To: mpls@ietf.org Message-id: <03af01c66841$e1338210$1d736e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Subject: [mpls] Some questions about draft-ietf-mpls-ldp-p2mp-00 (LDP-P2MP) X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1181568418==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1181568418== Content-type: multipart/alternative; boundary="Boundary_(ID_QSwPJutYfMaUbPieArkAnQ)" This is a multi-part message in MIME format. --Boundary_(ID_QSwPJutYfMaUbPieArkAnQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi, all, I have read draft-ietf-mpls-ldp-p2mp-00 and have a few quesitons. 1. about choosing upstream LSR. As defined in 2.3.1.1: If there are more than one such LDP peers, only one of them is picked. ^^^^^^^^^^^^^^^^^^^^^^^^^^^ The question is: How to choose the "Only One". It may depend on the LSR's IP address, or priority or others. This draft doesn't describe the method. I think it is better to make it clear to avoid confusion. 2. About the MP2MP. The methodology to build multicast LSPs described in this draft are similar to PIM. P2MP seems very similar to SSM. As to MP2MP, I think it is very similar to BiDir-PIM, which is described in draft-ietf-pim-bidir-08.txt. BiDir model has some advantages in some environment.For example, reduce the forwarding entry number. But is this the most popular topology in the network? It assumes all receivers will send data to all other receivers in the same group, but I think ASM model defined by PIM-SM may be more prevalent. Will MP2MP or this draft consider more on ' M to N' delivery model and don't assume a receive to be a sender? Thanks! BTW, I found a few minor editorial mistakes: There are double 'over over' in 4.2.1.5.1 and 4.2.1.5.2. In section 5 line 2, 'more then' should be 'more than'. --Boundary_(ID_QSwPJutYfMaUbPieArkAnQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi, all,
   
    I have read draft-ietf-mpls-ldp-p2mp-00 and have a few quesitons. 
   
    1. about choosing upstream LSR.
      As defined in 2.3.1.1:
         If there are  more than one such LDP peers, only one of them is picked.
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^           
      The question is: How to choose the "Only One". It may depend on the LSR's
      IP address, or priority or others. This draft doesn't describe the method.
      I think it is better to make it clear to avoid confusion.
     
    2. About the MP2MP.
      The methodology to build multicast LSPs described in this draft are similar
      to PIM. P2MP seems very similar to SSM. As to MP2MP, I think it is very
      similar to BiDir-PIM, which is described in draft-ietf-pim-bidir-08.txt.
     
      BiDir model has some advantages in some environment.For example, reduce the
      forwarding entry number. But is this the most popular topology in the network?
      It assumes all receivers will send data to all other receivers in the same group,
      but I think ASM model defined by PIM-SM may be more prevalent. Will MP2MP
      or this draft consider more on ' M to N' delivery model and don't assume a
      receive to be a sender?
     
 Thanks!
 
 BTW, I found a few minor editorial mistakes:
 There are double 'over over' in 4.2.1.5.1 and 4.2.1.5.2.
 In section 5 line 2, 'more then' should be 'more than'.
   
--Boundary_(ID_QSwPJutYfMaUbPieArkAnQ)-- --===============1181568418== 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 --===============1181568418==-- From mpls-bounces@lists.ietf.org Wed Apr 26 09:35:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYk8M-0007vo-VA; Wed, 26 Apr 2006 09:32:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYk8L-0007vj-HZ for mpls@ietf.org; Wed, 26 Apr 2006 09:32:45 -0400 Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYk8L-0004cB-1S for mpls@ietf.org; Wed, 26 Apr 2006 09:32:45 -0400 Received: from 176.red-80-34-174.staticip.rima-tde.net ([80.34.174.176] helo=[192.168.1.44]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1FYk8G-0000yt-3t; Wed, 26 Apr 2006 15:32:44 +0200 Message-ID: <444F7673.6050709@pi.se> Date: Wed, 26 Apr 2006 15:32:35 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Subject: Re: [mpls] consolidated response to Q12/15 on T-MPLS References: <4449589E.8020808@pi.se> <7.0.1.0.2.20060424101520.0526e898@comcast.net> <9373EA68-01ED-417E-BD87-FA079E6DC08F@cisco.com> <444CEE72.2000604@employees.org> In-Reply-To: <444CEE72.2000604@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: "Thomas D. Nadeau" 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: , Errors-To: mpls-bounces@lists.ietf.org All, (taking the chair hat off) I agree with Scott here. This one of the rasons why we have put effort on writing the (g)mpls-change-process. IETF should have conrol over the MPLS protocols, "non-MPLSing" T-MPLS just makes this harder. Insisting in renaming would just feed the trolls that want split out an ITU-MPLS. (hat back on - my kids tells me I looks ridiculous in a hat ;) ) but anyway please feel free to have opinions on the (re-)naming issue. /Loa Scott W Brim wrote: > On 04/24/2006 11:13 AM, Thomas D. Nadeau allegedly wrote: > >> There were no comments to the contrary as >>far as I can tell. That is, no one commented >>on the list or at the meeting that leaving >>MPLS in the name as okay. I did however, hear >>at least 3 responses to explicitly strike MPLS >>from the name. > > > I spoke against insisting on renaming, although maybe not on this list. > So far the ITU-T's stated intention is to define a subset of MPLS, not > to create something new. See their liaison: "The intent of these > Recommendations is not to change MPLS but rather to identify a subset of > existing MPLS necessary and sufficient to provide connection-oriented > packet transport." There is no need or advantage to asking them to take > "MPLS" out of their name until it is clearly no longer a subset. That > will depend on how the current discussion goes. Let's not create the > future we are concerned about. > > You bring up trademark. That's unrelated -- it's not the IETF and the > ITU, it's between the IETF and whoever trademarked something with "MPLS" > in it. > > Thanks ... Scott > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Apr 26 16:21:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYqSB-0007cd-Ae; Wed, 26 Apr 2006 16:17:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYqSA-0007cY-6w for mpls@ietf.org; Wed, 26 Apr 2006 16:17:38 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYqS9-0002tN-SV for mpls@ietf.org; Wed, 26 Apr 2006 16:17:38 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 26 Apr 2006 16:17:36 -0400 X-IronPort-AV: i="4.04,158,1144036800"; d="scan'208"; a="87301020:sNHT32286096" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3QKHZTL003048; Wed, 26 Apr 2006 16:17:35 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Apr 2006 16:17:34 -0400 Received: from [161.44.71.206] ([161.44.71.206]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Apr 2006 16:17:33 -0400 In-Reply-To: <444F7673.6050709@pi.se> References: <4449589E.8020808@pi.se> <7.0.1.0.2.20060424101520.0526e898@comcast.net> <9373EA68-01ED-417E-BD87-FA079E6DC08F@cisco.com> <444CEE72.2000604@employees.org> <444F7673.6050709@pi.se> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [mpls] consolidated response to Q12/15 on T-MPLS Date: Wed, 26 Apr 2006 10:58:05 -0400 To: Loa Andersson X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 26 Apr 2006 20:17:33.0777 (UTC) FILETIME=[73DC3C10:01C6696E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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: , Errors-To: mpls-bounces@lists.ietf.org > All, > > (taking the chair hat off) > > I agree with Scott here. This one of the rasons why we have > put effort on writing the (g)mpls-change-process. All things being equal, if the change process was followed, I think the situation would be quite different here. Unfortunately, things aren't equal because they (ITU) didn't follow the process, and so we are in this situation. This also begs the question of will this happen again in the future? I wonder if there is some way to rewind the process within the ITU and have the document start over there and go through the liaison and g/mpls-change-process? Not being an ITU process geek, I have no idea. > IETF should have conrol over the MPLS protocols, "non-MPLSing" > T-MPLS just makes this harder. Insisting in renaming would > just feed the trolls that want split out an ITU-MPLS. If T-MPLS is a true sub-set of MPLS then the naming is not so much of an issue IMHO. That is, if T-MPLS is simply a (configurable) subset of functionality. However, it is clear that the existing document as well as recently announced amendments to it, are straying from what I defined as a subset. In particular, the OAM as defined is *completely* different from what the IETF specifications stipulate, and there are reserved labels w/o semantics. In the case of the latter, there have been recent follow-on contributions that are taking a stab at defining these reserved labels, and these are troubling, especially based on the discussion of interop. that was voiced earlier. In this case, I think it is damaging to call the specification "*-MPLS" because it forms the basis for an "ITU-MPLS" that can then not only wildly diverge from what we have defined here (and what is deployed and certainly working!), but also be confused with said deployed version in the marketplace. > (hat back on - my kids tells me I looks ridiculous in a hat ;) ) I won't comment on that. *) --Tom > > but anyway please feel free to have opinions on the (re-)naming > issue. > > /Loa > > Scott W Brim wrote: >> On 04/24/2006 11:13 AM, Thomas D. Nadeau allegedly wrote: >>> There were no comments to the contrary as >>> far as I can tell. That is, no one commented >>> on the list or at the meeting that leaving >>> MPLS in the name as okay. I did however, hear >>> at least 3 responses to explicitly strike MPLS >>> from the name. >> I spoke against insisting on renaming, although maybe not on this >> list. >> So far the ITU-T's stated intention is to define a subset of >> MPLS, not >> to create something new. See their liaison: "The intent of these >> Recommendations is not to change MPLS but rather to identify a >> subset of >> existing MPLS necessary and sufficient to provide connection-oriented >> packet transport." There is no need or advantage to asking them >> to take >> "MPLS" out of their name until it is clearly no longer a subset. >> That >> will depend on how the current discussion goes. Let's not create the >> future we are concerned about. >> You bring up trademark. That's unrelated -- it's not the IETF and >> the >> ITU, it's between the IETF and whoever trademarked something with >> "MPLS" >> in it. >> Thanks ... Scott >> _______________________________________________ >> mpls mailing list >> mpls@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/mpls > > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Apr 28 11:51:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVDe-00072o-B1; Fri, 28 Apr 2006 11:49:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVDd-00072b-2z for mpls@lists.ietf.org; Fri, 28 Apr 2006 11:49:21 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZVDa-00014y-IH for mpls@lists.ietf.org; Fri, 28 Apr 2006 11:49:21 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 17:49:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Apr 2006 17:49:15 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026035E8648@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MPLS2006 INTERNATIONAL CONFERENCE] Reminder, CFP : one month left Thread-Index: AcZMwb4AKzPvaPWxThKRbiKvrV7lrweGQVzw From: "MOIGNARD Renaud RD-CORE-LAN" To: X-OriginalArrivalTime: 28 Apr 2006 15:49:17.0125 (UTC) FILETIME=[4E558F50:01C66ADB] X-Spam-Score: 0.1 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Subject: [mpls] [MPLS2006 INTERNATIONAL CONFERENCE] Reminder, CFP : one month left 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="===============0242647411==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0242647411== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66ADB.4DACE3D8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66ADB.4DACE3D8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MPLS 2006 INTERNATIONAL CONFERENCE=20 http://www.mpls2006.com=20 OCTOBER 15-18, 2006=20 WASHINGTON, DC=20 Reminder : one month left for the paper submission !!! CALL FOR PRESENTATION=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 MPLS 2006 (< http://www.mpls2006.com>), the = 9th Annual International Conference on MPLS and Related Technologies, = will be held on October 15 through 18, 2006, in Washington, DC. The = Program Committee of MPLS2006 is soliciting presentation proposals for = the conference. If you wish to suggest a particular topic for possible = presentation at the event, please send a one page proposal (including = speaker's contact information) to the attention of the Technical Program = Committee at mpls2005-cfp@isocore.com by May 26, 2006. This year's conference will include, but will not be limited to, the = following=20 topics:=20 - MPLS in multi-area and multi-AS networks=20 - Point-to-multipoint MPLS and applications=20 - Supporting multicast in MPLS VPNs and for VPLS=20 - Single and Multi-hop Pseudowire placement, setup and management=20 - Providing QoS in MPLS networks=20 - MPLS network management=20 - OAM for MPLS networks=20 - MPLS in the Next Generation Network=20 - Voice over IP/MPLS=20 - IMS an IPTv over MPLS=20 - Triple-play applications on MPLS=20 - MPLS-enabled Advanced services and converged networks=20 - Interworking and migration for MPLS and GMPLS=20 - Multi-layer networks and integration with non-packet technologies=20 - Deploying, interworking and operating L2 and L3 MPLS VPNs=20 - MPLS deployment experience: scaling, performance and security=20 - Testing the technology: MPLS test tools and experience=20 - Protection, restoration and reliability=20 - Network processors for MPLS and GMPLS=20 - MPLS/GMPLS control plane resilience, scaling and robustness=20 - MPLS TE applications of the Path Computation Element (PCE)=20 - Motivations and requirements for extending MPLS into the access = network=20 - MPLS and IPv6=20 The program committee is looking for original and unpublished work to = continue the tradition initiated by this conference in 1998 of covering = cutting-edge topics. Presentations addressing new technologies and = operational experience are solicited from network equipment vendors, = service providers, the research community, and government and enterprise = users. Renaud Moignard , Ph. D.=20 Head of R&D team - IP/MPLS networks france telecom R&D / CORE/CPN 2, avenue Pierre Marzin, 22307 Lannion C=E9dex, France Tel : +33 2 96 05 35 28 - Fax : +33 2 96 05 18 52 e-mail : renaud.moignard@francetelecom.com ------_=_NextPart_001_01C66ADB.4DACE3D8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [MPLS2006 INTERNATIONAL CONFERENCE] CFP
MPLS 2006 INTERNATIONAL = CONFERENCE=20
http://www.mpls2006.com
OCTOBER 15-18, 2006
WASHINGTON, DC

Reminder : one month left for the paper submission=20 !!!

CALL FOR = PRESENTATION=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
MPLS 2006 (<http://www.mpls2006.com>), the 9th Annual International Conference on MPLS and = Related=20 Technologies, will be held on October 15 through 18, 2006, in = Washington, DC.=20 The Program Committee of MPLS2006 is soliciting presentation proposals = for the=20 conference. If you wish to suggest a particular topic for possible = presentation=20 at the event, please send a one page proposal (including speaker's = contact=20 information) to the attention of the Technical Program Committee at=20 mpls2005-cfp@isocore.com by May 26, 2006.


This year's conference will = include, but will=20 not be limited to, the following
topics:

- MPLS in multi-area and multi-AS = networks
- = Point-to-multipoint MPLS=20 and applications
- = Supporting=20 multicast in MPLS VPNs and for VPLS
-=20 Single and Multi-hop Pseudowire placement, setup and management =
- Providing QoS in MPLS networks =
- MPLS network management
- OAM for MPLS networks
- MPLS in the Next Generation = Network
- Voice over IP/MPLS
- IMS an IPTv over MPLS
- Triple-play applications on MPLS =
- MPLS-enabled Advanced services and = converged=20 networks
- Interworking = and migration=20 for MPLS and GMPLS
- = Multi-layer=20 networks and integration with non-packet technologies
- Deploying, interworking and operating L2 = and L3 MPLS=20 VPNs
- MPLS deployment = experience:=20 scaling, performance and security
-=20 Testing the technology: MPLS test tools and experience
- Protection, restoration and = reliability=20
- Network processors for MPLS = and=20 GMPLS
- MPLS/GMPLS = control plane=20 resilience, scaling and robustness
-=20 MPLS TE applications of the Path Computation Element (PCE) =
- Motivations and requirements for = extending MPLS into=20 the access network
- MPLS = and=20 IPv6


The program committee is looking = for original=20 and unpublished work to continue the tradition initiated by this = conference in=20 1998 of covering cutting-edge topics. Presentations addressing new = technologies=20 and operational experience are solicited from network equipment vendors, = service=20 providers, the research community, and government and enterprise=20 users.


Renaud=20 Moignard , Ph.=20 D. 
Head of R&D team - IP/MPLS = networks
france telecom R&D / CORE/CPN
2,=20 avenue Pierre Marzin, 22307 Lannion C=E9dex, France
Tel : +33 2 96 05 35 28 - Fax : = +33 2 96 05=20 18 52
e-mail :=20 renaud.moignard@francetelecom.com


------_=_NextPart_001_01C66ADB.4DACE3D8-- --===============0242647411== 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 --===============0242647411==--